damentz-afk: gn8
AirCanada: so i was a long-time user of the 9200se with the xorg radeon driver, but i just bought an x1650 pro. using kubuntu 8.04, my only option for 3d acceleration is the catalyst driver. what i would really like, is that i get the same wonderful stabilty on the rv535 as i got on the rv280, using the radeon or even radeonhd driver. is there a quick route to nirvana ? cos i tried enabling the Tormod Volden xorg-edgers repo, but t
gentooer: I just got a cheap X1300 agp (r500) to play around with KMS. should i be using radeon or radeonhd?
gentooer: (i'd also like to try a few older games)
adamk_: gentooer, radeon. I don't *believe* radeonhd supports kms yet.
gentooer: ok thanks
hifi: what is KMS?
agd5f: hifi: kernel modesetting
agd5f: hifi: moving modesetting to the drm
hifi: ah, thanks
Nash_13_: help with radeon Xpress 200M
Nash_13_: help with radeon Xpress 200M
lbt: This bug is crashing my radeon r500 - I'm using xorg/mesa from Nov'08 .... https://bugs.freedesktop.org/show_bug.cgi?id=18452
lbt: I've written a LD_PRELOAD intercept that lets me see/change the parameters to glLoadProgramNV
lbt: but I don't know what to change... https://bugs.freedesktop.org/attachment.cgi?id=20495
agd5f: Nash_13_: just ask your question
Nash_13_: agd5f, I need
Nash_13_: agd5f, to install driver ati radeon xpress 200M for intrepid ibex
Nash_13_: agd5f, because the private driver don´t work good
lbt: So anyone know how to write a minimal vertex program?
Nash_13_: help with radeon Xpress 200M
chithead: Nash_13_: that doesn't make sense, ubuntu 8.10 comes with recent kernel and xf86-video-ati which should work out-of-the-box. in any case, you better ask in #ubuntu
lbt: Nash_13_: you really need to askin
z3ro: lbt: the spec shows you how to write a simple vertprog.
lbt: z3ro: I've never done it - where would I start?
lbt: any pointers gratefully rcvd :)
Nash_13_: chithead, yes but that driver is broken i have tu install de private and after read that that has problem
logari81: Nash_13_: https://help.ubuntu.com/community/RadeonDriver
chithead: no idea what private means in this context
z3ro: lbt: http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_program.txt
Nash_13_: logari81, exist a way that install from a cd the radeon driver for mi video card
z3ro: question #73 shows a reasonably complex program that does basic lighting
z3ro: but all you actually need is vertex.position, and maybe vertex.color if you want it looking pretty
lbt: z3ro: looking - ideally I'm looking for a bare minimum that I can iterate over and build up
logari81: Nash_13_: you just need to uninstall the fglrx driver and reinstall mesa, I suppose this is also possible using the installation CD as software source
lbt: I'm *very* new to this so I don't really grog the whole context of what's going on
Nash_13_: logari81, how I can do that??
z3ro: lbt: then the best thing to do is read the spec
chithead: Nash_13_: that is distribution specific
Nash_13_: logari81, I unistall xserver-ati-video-driver
lbt: OK - roughly, what does that program I linked to do?
Nash_13_: chithead, I want to install a free drivers
lbt: and what tool would I use to create it?
lbt: do I pass the raw ascii to glLoadProgramNV for it to 'compile' or do I need to pass 'object' code in?
chithead: Nash_13_: ubuntu already comes with the free drivers, if you messed up your system by installing software outside the package manager it is often easiest to reinstall everything. further questions best ask in #ubuntu
z3ro: lbt: you should use the ARB version, and plain text
lbt: I'm trying to fix a bug in neverwinternights
lbt: so I don't have that luxury
lbt: :)
Nash_13_: chithead, this driver work bad and I install private but was worse
lbt: I just get to intercept their calls via LD_PRELOAD
z3ro: ok, well, I linked the ARB spec, so you should look at the NV one instead.
logari81: Nash_13_: look at the link I gave you, you just have to run
logari81: sudo apt-get remove --purge xorg-driver-fglrx
logari81: sudo apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri
logari81: sudo dpkg-reconfigure -phigh xserver-xorg
lbt: I'm guessing that they tickle a bug
lbt: http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_program2.txt ?
lbt: I found that and added it to the bug report for Joel (and I)
Nash_13_: logari81, with that I will fix my problem
z3ro: google shows http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_program.txt but 2 might just be an updated version.
logari81: Nash_13_: after that edit your /etc/X11/xorg.conf and make it look like this one
logari81: http://pastebin.ubuntu.com/70986/
lbt: Given that that code works on other OSes
lbt: I'm wondering if there is a bug in the implementation in dri_radeon
lbt: and that was what I wanted to help find
logari81: Nash_13_: restart your Xserver and you will probably be ok
Nash_13_: logari81, that configuration is for radeon xpress 200M
logari81: should be fine with xpress 200M
Nash_13_: logari81, I will probe that thanks
lbt: so I'm in a position to help test intelligently - but realistically I doubt I'll get far just reading the spec
z3ro: hi bridgman
bridgman: hi z3ro; still in the (other) great white north ?
bridgman: it's -16 here, or it was last night, howzit there ?
z3ro: I think about -2 or around there... I have a really warm jacket though, so I only notice it on my face and ears. :P
z3ro: -16 would be pretty nasty...
bridgman: I'm assuming you're on Celsius over there ? Too cold for Farenheit, too warm for Kelvin ?
z3ro: yeah
z3ro: celsius
z3ro: hmm, we're up to 1degree C now :P
bridgman: wow, warmer than I expected; we really were -16 celsius; you know it's cold when the dog stops at the front door like it ran into a wall of glass
bridgman: must be nice, maybe I should move there and get away from the cold (???)
z3ro: hehe well back in NZ it's 17C (5:46am)
bridgman: that's more civilized; then again it's summer there isn't it ?
bridgman: I'm gradually losing faith in the idea of picking one place and living there; seems like you have to move around to keep the weather decent
z3ro: hmm I think so... the seasons are kind of weird though.
bridgman: yeah, I guess when you have a small piece of land in the middle of a large ocean you get whatever happens to be blowing around in the area
z3ro: I'm really happy to get my own place :) plus helsinki is pretty cool (AHAHAHA ;)
z3ro: yeah
bridgman: glad you're settling in ok; if all else fails there's always vodka
bridgman: bye ;)
z3ro: heh
z3ro: well, if I could legally buy vodka here. =/
z3ro: hmm this looks nice for GPU's too: http://lkml.org/lkml/2008/12/4/401
agd5f: ossman: pong
ossman: agd5f, you need to have a look at that latency of yours ;)
ossman: did you see my question about double buffering?
agd5f: ossman: yeah, sorry, weekends are often non-driver time :)
agd5f: yeah, I saw that. nothing to prevent it
ossman: huh?
agd5f: ossman: ie there are no fences on the buffers, so you may end up overwriting a frame
ossman: oh right... that question. I had several :)
ossman: is that solvable in a clean way?
agd5f: I think I missed your other question, let me scan the scroll back
ossman: i.e. can we check when the GPU is done with the buffer?
ossman: I have follow-ups, so don't bother
ossman: we can redo it from the beginning :=)
agd5f: ok
glisse: ossman: with memory manager it should work out of the box without userspace knowing about it
agd5f: ossman: we need memory management and airlied and glisse's new command submission code
glisse: basicly with each cs kernel associate a fence
ossman: is any of this in what airlied sticks into the fedora packages?
glisse: maybe dunno
agd5f: ossman: there are scratch registers that the CP can use and you can write timestamps to them at different points in the pipeline
ossman: those are limited though, so it would be something that would have to be coordinated
agd5f: and use those to determine when buffers can be freed and the caches are flushed, etc,
agd5f: ossman: right, that's why we need the new memory manager and fence code
ossman: in the mean time, alternating between two buffers would solve it for most cases
glisse: ossman: i don't think you should worry
agd5f: ossman: fedora 10 has most of this
glisse: because you should not see any effect with today path
ossman: glisse, why not?
agd5f: but, things are likely to change
glisse: as things are scheduled linearly
ossman: unless you have turned off xv dma :)
glisse: ie things you send to the kernel at time t will be executed and flushed before things you do at time t+dt
ossman: btw, keithp talked about the intel driver doing some voodoo with the GART for integrated graphics to avoid having to copy data. has anyone looked at doing that for the integrated ati chips?
glisse: ossman: we will do things like that with memory manager
glisse: it's not voodoo
glisse: it's just changing GART table dynamicly
ossman: "creative use of aperture mappings" then ;)
agd5f: ossman: the gart is dynamic now
agd5f: now as in memory manager stuff
ossman: yeah, the underlying principle was simple enough. but it was not how the gart had been used previously, so "voodoo" :)
ossman: uses the term very loosly
glisse: ossman: well intel did have some hard problem to solve
glisse: because for instance tiling reshuffle data in non predictable way btw ram chips
glisse: so cpu could not reconstruct memory layout easily
ossman: I have some vague memory of ati talking about dedicated memory even on integrated graphics. so are these problems with having to rely heavily on the GART soon a thing of the past?
ossman: I guess I should s/ati/amd/ these days though :)
glisse: ossman: well amd chipset stole a fragment of ram at startup
glisse: while iirc intel chipset allocate ram dynamicly
glisse: note that amd chipset also allocate more memory dynamicly
glisse: but the stole ram area make things looks like if there vram
ossman: but there was something about having dedicated chips for the graphics, basically having real VRAM on the motherboard
agd5f: ossman: sideport
agd5f: it's for power saving
ossman: oh. so not a performance thing?
agd5f: not really. it gives us a buffer for scanout when chipset stuff is powered down or in low power modes
glisse: well vram is definitly more performant than ram
glisse: aren't this ram gddr3 ?
ossman: agd5f, but this is not used when in fully awake mode?
agd5f: ossman: it can be
agd5f: I don't recall all the details off hand
ossman: back to more tangible things
agd5f: glisse: I don't know what types of ram are normally used
ossman: I was thinking about how to solve the vsync thing more properly. but I guess the long term way forward relies on kernel buffer management
ossman: so what state is that in?
agd5f: ossman: generally useable
ossman: I read on phoronix something about dri2 and swap on vblank
glisse: even their vsync is a nightmare
ossman: do you have more details? because that sounds like an important piece of this
glisse: ossman: the problem here is what hw offer
glisse: and also what X does
ossman: with interrupt on vblank, and some IPC, I think it should be possible to solve
glisse: what X lacks is the notion of complete frame
ossman: doesn't composite have that though?
glisse: ossman: only fast solution i can see is using pageflipping
ossman: that was the plan I was hoping to test
glisse: but then you got the problem of coherency btw buffer
ossman: the docs hint that the hw can do pageflipping on vblank by itself, but it doesn't really explain it properly
glisse: well even in fully composited situation i think they are issue
ossman: which was my question to agd5f, why his double buffering patch uses wait on vblank
glisse: would need to talk with krh because i can't remember of the usecase we comeup with
agd5f: ossman: we need to know when it's safe to flip the page
ossman: agd5f, but the docs talk about writes to the frontbuffer regs being delayed until vertical retrace
glisse: agd5f: i don't think you need to wait
glisse: just write new offset
agd5f: I seem to recall there being some issue though, maybe not
glisse: hw will pick it up at next vblank
glisse: you can even ask the hw which address is in use
glisse: ie does last write was taken into account
ossman: glisse, how will that be handled in the new system though?
ossman: where mmio access isn't allowed
glisse: ossman: would be put into cs
agd5f: ossman: via command buffer reloc for the crtc address
ossman: agd5f, the what now?
ossman: glisse, I may not have a complete understanding here, is cs the command stream to the kernel, or to the card (i.e. the fifo ring)?
agd5f: ossman: in mem manager world it's all handles rather than offsets, so the correct address gets fixed up when the drm checks the command buffer
ossman: yeah, but which buffer you want to render to kind of hinges on which buffer the card is using :)
ossman: so you need to know if the flip has happened or not
glisse: ossman: well we might use an ioctl like getparam which anyway can be renamed :)
glisse: so for instance you could ask ioclt to change offset and block until offset is updated or just change offset and query to know when offset have, or change offset and ask for an interrupt
glisse: see many solutions :)
ossman: they did not go through the cs though :)
agd5f: we could also special case crtc regs in the command checker
agd5f: and do the right thing
ossman: I'm thinking that we should do triple buffering in order to avoid throttling anyone
glisse: ossman: well anythings we pick should allow tripple, quadruple, ... :)
ossman: one buffer being scanned out, one waiting to be flipped, and one that can be rendered to while we're waiting for the flip "slot" to become available
ossman: glisse, I meant more like, three is the minimum we need :)
glisse: ossman: quadruple might be usefull in stereoscopic case
ossman: right
ossman: does anyone use that these days? that hype sort of died out
ossman: at least for gaming
agd5f: ossman: high end visualization apps still use it I think, nothing consumer oriented
ossman: k
ossman: the problem I'm trying to solve is that xv does not currently fail very gracefully when the client is feeding frames faster than it can get rid of them
ossman: the wait for vblank is of course a big problem there, but I figured I could also solve a related problem
ossman: namely when the video has a higher framerate than the monitor
bridgman: glisse; the issue with VRAM sideport not being faster is that the bus is very narrow, 16 bits IIRC. I think that hooks up to a single memory chip. Resulting bandwidth and performance is about the same as what you get going through HT to the much wider system RAM
bridgman: the difference is that you can refresh screen without having to keep waking up the CPU to use its memory controller
glisse: poor igp system
bridgman: and the memory controller for a single skinny vram can use a lot less power than the main multi-bank interleved cached blah blah controller
bridgman: yep, it's not easy being the graphics component in a cpu-centric system ;)
ossman: and you don't have to interrupt other memory access with continuous ramdac accesses?
ajax: bridgman: how insane would it be to switch in and out of sideport dynamically?
bridgman: I think we do it today in the closed driver; will ask. You can also interleave sideport and system RAM to get a bandwidth & performance boost, but that's real nasty for power management and I don't think we use it
bridgman: ossman; yep, but the savings isn't as big as you might hope...
ossman: is a cynical man with very little hope left
bridgman: has been through cynical and come out the other side; there are huge opportunities for improvement, there just aren't a lot of magic bullets
ajax: i'll put that on the todo list
ajax: not my todo list. it's so pleasant to be able to delegate.
ossman: :P
spstarr_work: airlied: moving onto f11 kernels? should I follow suit?
spstarr_work: oh, just a rollup patch
gentooer: anyone know where I can find a patch to apply to a vanilla 2.6.28rc to enable KMS support for a r500?
dijenerate: hi all
spstarr_work: gentooer: there's patches in Fedora CVS
spstarr_work: i donno they might apply
gentooer: ok i'll take a look
dijenerate: anyone here using powernow with fglrx and a turion?
dijenerate: I need some help please
gentooer: dijenerate, you should probably ask in #ati
dijenerate: ok, thnx
spstarr_work: " More I can't believe its not AGP fixes."
spstarr_work: heh airlied
spstarr_work: i didnt get to try yesterday, i will when i turn laptop on today
spstarr_work: oh I see, you added some more scratch areas
spstarr_work: er reordered them
spstarr_work: then set up the GART allocation
crossone: Any guy get this card working on F10? ATI Radeon HD3650 PCI-E 512
crossone: about system effects
adamk_: crossone, There are no 3D open source drivers for that video card. Novell is supposedly working on this. There is no available estimated time they will be complete
adamk_: crossone, Till then you will have to use the fglrx drivers.
crossone: adamk_, tks I was trying to find u :)
crossone: adamk_, Ppl said that I could have modified version of xorg.cong
crossone: adamk_, send me the link for this project... I will not take ur time
adamk_: There is no real website for the development of these open source drivers. There is some information available here, though: http://www.phoronix.com/forums/forumdisplay.php?f=43
tlp: yeah, I'd watch Phoronix... subscribe to their feed. They seem to be on top of everything.
crossone: adamk_, tks...
crossone: have to go, bye
adamk_: So this keeps bugging me. If I have two 1280x1024 monitors next to each other, and start a game at 1024x768, fullscreen, the monitors change resolution to 1024x768, clone each other, but don't display the game. I believe the game is actually being displayed at 1024x768+1280+0.... Or maybe 1024x768+1024+0. Does that make sense?
adamk_: I *think* it's because Xorg considers the monitor on the right to be the primary monitor?
rnoland: adamk_: honestly I don't think x cares...
rnoland: what i used to see was that VGA was always primary, and DVI was secondary...
rnoland: on my radeon...
rnoland: I never figured a way to change it, at least from gnomes perspective...
adamk_: Hmmm.
spstarr_work: crossone: I have that card, didnt try composite stuff yet
mjg59: Hm
mjg59: Enabling power management on this M86 saves 8W.
mjg59: Some kind of fail.
spstarr: airlied: fail
spstarr: same corruption with -137
airlied: spstarr: ah well just have to wait for the cards then :)
spstarr: it takes AMD that long to ship? :)
airlied: they are stuck somewhere.... probably .au customs.
spstarr: cooks some shrimp egg rolls
spstarr: having moved into my new place, its nice that i can have laptop and hack while I cook
spstarr: multitasking at its best
rvalles: spstarr: as long as boiling oil is far away from the laptop :P
spstarr: hehehe
stoned: hi
stoned: please explain your problem here
stoned: include links to any log files
peteweez: OK essentially I am using the vesa driver now with no probs
stoned: provide as much specific info as you can
peteweez: it's great for everything except video
peteweez: I can get an xorg.log for you with the other drivers, radeon, radeonhd, and fglrx if you wish
peteweez: or anything else
peteweez: One interesting thing to me...
peteweez: when I get the green blobs and then the white screen with radeon drivers, I get weird messages that don't look like xorg messages
peteweez: like BLANK CRTC 0 SUCCESS
peteweez: stuff like that
peteweez: does that mean anything to you?
airlied: they are normal message for radeon.
peteweez: OK
peteweez: but green blobs are not
peteweez: With fglrx, I believe the error that causes X to stop is this
peteweez: symbol lookup error: /usr/lib/xorg/modules/drivers//fglrx_drv.so: undefined symbol: firegl_QueryMCRange
airlied: peteweez: pastebin a logfile from radeon
peteweez: OK I will have to log off since I am using an X-based IRC client
peteweez: Hello again...I tried radeon and this time got a blank white screen
peteweez: no green blobs
peteweez: had to ctrl-alt-bksp
peteweez: Does radeon require any kernel modules to be loaded?
peteweez: And should I have rmmod-ed fglrx.ko?
peteweez: here is pastebin of xorg.log
peteweez: http://rafb.net/p/FiaPPP55.html
airlied: yup don't have fglrx around it can break things.
peteweez: (WW) RADEON(0): R600 support is mostly incomplete and very experimental
peteweez: I don't like the sound of that
peteweez: OK anything else I can give you?
airlied: I assume its some sort of laptop?
peteweez: another Xorg.log with no fglrx loaded
peteweez: yeah
peteweez: Asus F8VA-B1
peteweez: it's pretty new...has the centrino 2 montevina platform
peteweez: radeonhd is reputed not to work with Asus laptops with more than 2GB ram
peteweez: h/o I'll show you where I read that
airlied: peteweez: is that the latest radeon driver or from a distro?
peteweez: Debian lenny
peteweez: http://www.x.org/wiki/radeonhd#head-d0cfd39d1b149a43f0c1d862f21f4b3ddcb43ae2
airlied: looks old, is lenny experimental? or can you try and build from git?
peteweez: lenny is testing
peteweez: which is older than unstable, which is older than experimental
peteweez: but newer than stable
peteweez: I can get sources, yes
airlied: I think you might have more hope of getting a screen with experimental X.org packages.
peteweez: Where is the upstream source?
airlied: but even getting latest -ati git would work
chithead: debian has been in freeze for months, the x stuff in unstable and testing is pretty much outdated
airlied: git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
peteweez: and will I have to recompile the entire x server?
airlied: peteweez: not for -ati.
peteweez: ok
peteweez: Yeah I compiled fglrx from source
peteweez: it compiled OK but didn't seem to want to actually do anything
peteweez: lol
chithead: of course it would help to have a new beta release tagged so it could be included in debian experimental and other distros :)
airlied: fglrx doesn't have source
peteweez: well, you know what I mean
peteweez: the upstream ati installer package that you sorta compile
peteweez: their lame attempt at making blobs interface with F/OSS kernels
peteweez: why don't they just release the d**n source and let the community take care of the maintenance?
peteweez: so this git repository will get the radeon source?
airlied: peteweez: yes.
airlied: sh autogen.sh --prefix=/usr
tlp: peteweez: I think that's what they're working toward now :)
peteweez: tlp: are you serious?
peteweez: I know that ati has always been kinda-sorta OK with the FOSS movement, but not to that extent!
tlp: things have changed a lot recently.
peteweez: I always thought that was more of an Intel-type thing to do
chithead: I don't think this is going to happen, and I'm not aware of any x developer who has asked for this
tlp: there are a lot of IP hurdles to clear for documentation/foss code, as I understand it, but they're working on it.
peteweez: Yeah stupid me I picked the laptop with the ATI chip instead of nVidia because I was pissed with nVidia about their binary blobs
peteweez: so I traded one binary blob manufacturer for another
tlp: R500 already has docs and 3D support, which sort of appeared rapidly due to the similarity between R300. The newer chipsets are entirely different and had to be brought up from scratch.
peteweez: tlp: They are releasing specs
peteweez: but I doubt they will outright GPL fglrx
tlp: well, no, it won't be fglrx
peteweez: and I'm not sure the documentation/specs of the 3D acceleration is out there yet
tlp: it'll be a new driver
tlp: phoronix follows this stuff, you might check there.
peteweez: uh I think I just had a major n00b moment
peteweez: I haven't used git before...cvs and svn yes, but not git
peteweez: ~$ git git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
peteweez: git: 'git://git.freedesktop.org/git/xorg/driver/xf86-video-ati' is not a git-command. See 'git --help'.
airlied: git clone
peteweez: ah
peteweez: that worked
peteweez: tlp: have you heard microsquish's bs about not releasing hardware specs?
peteweez: they actually want people like ATI to maintain secrecy of the internal workings of their hardware for their evil DRM platform
tlp: I don't know who or what a microsquish is.
peteweez: microsoft
tlp: ;p
peteweez: microsquish, n.: a monopolistic software company that maintains supremacy not by superior products but by sheer inertia and making things incompatible with competitors' software
peteweez: autogen.sh: line 9: autoreconf: command not found
peteweez: I'm missing autogen tools package or something?
peteweez: consults the gospel according to synaptic
peteweez: ah apt-get install autoconf
peteweez: configure.ac:38: error: possibly undefined macro: AC_DISABLE_STATIC
peteweez: If this token and others are legitimate, please use m4_pattern_allow.
peteweez: See the Autoconf documentation.
peteweez: configure.ac:39: error: possibly undefined macro: AC_PROG_LIBTOOL
peteweez: What happened?
airlied: install libtool
peteweez: OK
peteweez: anything else while I'm at it?
peteweez: bear in mind my Debian install is almost completely new
airlied: you might need some xorg devel but I've no idea what the packaegs are called.
peteweez: I can find them
peteweez: alright got the packages
peteweez: let's see what this does...
peteweez: any configure options I need to set?
peteweez: oops...
peteweez: atimodule.c:39: error: ‘PACKAGE_VERSION_MAJOR’ undeclared here (not in a function)
peteweez: atimodule.c:39: error: ‘PACKAGE_VERSION_MINOR’ undeclared here (not in a function)
peteweez: atimodule.c:39: error: ‘PACKAGE_VERSION_PATCHLEVEL’ undeclared here (not in a function)
peteweez: What the heck does it want now?
airlied: xorg-utils-dev or something like that
peteweez: OK I'm just going to apt-get xorg-dev
peteweez: which is a ~23 meg download but then I should have everything
airlied: xorg-utils-dev is also a separate package I tink
airlied: think
gentooer: if I want to try KMS/GEM, can I use xf86-video-ati and mesa from the mainline git or do I need to use airlied's git?
gentooer: or is there some other git I should be using?
airlied: you need to use radeon-gem-cs from my tree, but that hard part is getting a libdrm tyhat works.
gentooer: airlied, do i need to use the mesa from your tree as well? won't the modesetting branch from the mainline drm tree work?
airlied: no the modesetting API has diverged a bit.
airlied: and I have to spend some time fixing it all up.
peteweez: xorg-utils-dev does not exist
peteweez: nor does xorg-utils
airlied: forgets the package with the macros in it
airlied: xutils-dev
peteweez: haha that'll do it
peteweez: sorry for being such a pain in the backside...X and I never got along very well
peteweez: Aw crap looks like I need more dev packages
peteweez: missing a header fil
peteweez: e
peteweez: /usr/include/GL/glxint.h:28:19: error: GL/gl.h: No such file or directory
airlied: wierd it shuoldn't need GL in -ati
airlied: its in a libgl devel package or somewhere like that
peteweez: libgl1-mesa
airlied: not sure why you need that though.
peteweez: shouldn't ./configure check for that kinda thing?
peteweez: Hey it compiled!
peteweez: Now just to make install...
peteweez: wait should I apt-get-remove anything first?
peteweez: alright I make installed it
peteweez: now I will log off and try the radeon driver
peteweez: and prepare an Xorg.log for you in the event of an error
peteweez: still just a white screen
peteweez: http://rafb.net/p/fnZonm68.html
airlied: it looks a least a little more sane in the logfile.
peteweez: Well, that's something.
airlied: so it can see the LVDS which is at leasta good step 1
peteweez: Any idea what's wrong with it?
airlied: peteweez: sorry was afk, not sure, if you file a bug on bugs.freedesktop.org against radeon driver I'll see if I can figure it out some more.
airlied: try radeonhd to see if it works at all.. even with 4GB RAM it should still start.
peteweez: I've tried. It doesn't.
peteweez: What do you want in the bug report and I'll take care of it ASAP?
airlied: the logfile you posted as an attachment, I'm hoping Alex can take a look.
peteweez: Just the logfile...no other info?
peteweez: not a lspci or a uname -a or anything?
airlied: nope it should all be in the logfile.
peteweez: OK if you're sure that's all you need I can try to do that now.
peteweez: Thanks for everything.
airlied: peteweez: do you have a monitor you can plug-in to see if that lights up?
peteweez: airlied: 3 hours away at home, I do
peteweez: I'm going home the 18th
peteweez: I'm at colleg
airlied: if you get a chance try it with a VGA monitor, hopefully we can fix it before then.
peteweez: I think I'd get yelled at if I went in the computer lab and started screwing with their monitors, but what're they going to do?
peteweez: I doubt they'd call Public Safety on me :-P
spstarr: airlied: so, we both continue to wait :-)
airlied: my cards arrvied today.
airlied: they are at home.
airlied: my gf just told me.
peteweez: What would you like me to file the report against?
airlied: xorg driver/radeon
peteweez: OK
peteweez: filed
peteweez: http://bugs.freedesktop.org/show_bug.cgi?id=18969
peteweez: Thanks again.
tlp: airlied: which cards did you get?
airlied: tlp: I think an rv730 PCIE, rv350 AGP, and I think an rv410 PCIE
tlp: donations?
airlied: AMD via agd5f send me batches whenever he can find them
tlp: ah
gentoofu: girlfriend?
gentoofu: oh, still not married?
airlied: nope too lazy :)
gentoofu: lol