Nightwulf|work: hi all
libv: emmes: i just threw a 20 at a firegl v3100 to be able to play with this issue still
libv: emmes: so no need to drag anything from the suse office
libv: i hope to have it somewhere early next week
emmes: i would've brought you some card but that sounds reasonably cheap
libv: yeah, cheap enough :)
KasDra: guys, i was thinking about compile radeonhd. Im on Debian Squeeze, with uses radeonhd 1.2.1-2. Compile the driver will give me more acceleration? (My card is a Radeon X1200, r5xx.
yangman: 1.2.1 is ooooooooold
KasDra: i want to ask about kernel mode-setting. It will make ati better?
KasDra: yangman, on this case i will recompile the same version that is on my machine
woglinde: KasDra switching btw. vt's and xserver is faster
yangman: KasDra: what's the point in doing that?
kcodyjr: there is a downer to kms. it means rebooting to reload the graphics driver, and means recompiling to update it.
KasDra: yangman, compile it wont make it more specific from my card?
yangman: KasDra: no
KasDra: im using pre-compiled deb package
libv: woglinde: you do know what switching VTs and X then is reduced to, right?
libv: woglinde: changing memory content and waiting for 2d/3d engines to go idle.
libv: woglinde: no more safetynet.
woglinde: libv but its fast and no flickring
KasDra: if i want to get some new drivers, i will have to get the new xserver-xorg by dependencies, and then i will have to pick a lot of bugs from sid
libv: woglinde: but it loses its most important feature.
kcodyjr: i don't even see why it's strictly necessary to wait for the engines to go idle, since the kernel has the ability to just point the crtc at a different buffer
woglinde: libv hm?
libv: woglinde: why would you want to change from X to a VT?
libv: yes, exactly.
kcodyjr: libv, i can answer that. to get a shell in few enough cpu cycles that i can "kill -9 firefox" while it's got X so bogged down the mouse cursor moves by 8" jumps
kcodyjr: which also argues for the least possible monkeying with the graphics state.
libv: kcodyjr: true, but there are many other cases as well
libv: where you do want to have vga textmode or vesafb restored
kcodyjr: vga textmode has one advantage that will never die: dirt low power consumption on most chips
libv: kcodyjr: also, in such a cases, and there were times when browsers with their flashplayers and whatnot grabbed the keyboard
libv: s/in such a cases, and//
kcodyjr: but if you're running highly accelerated X then presumably you have the 1KW power supply, and maybe a dedicated circuit breaker.
libv: hrm... thinking another thought in the middle of typing leads to busted sentences
kcodyjr: yeah, flash is on my s**t list too.
libv: when the input devices are grabbed, you log in remotely and then kill the application
kcodyjr: i've seen that fail to recover
libv: and of course, restoring VT is never going to cover all cases, and you might kill X hard and it will not attempt to restore the VT
kcodyjr: that problem is implicitly handled in a kms world
libv: kcodyjr: are you sure?
libv: kcodyjr: s/implicitely/hopefully/
kcodyjr: not knowing the implementation with intimate detail, no.
libv: kcodyjr: but other functionality is sacrificed for it
kcodyjr: but, in principle, since the kernel owns the hardware, it can deal with graceless userland processes
libv: kcodyjr: if modesetting messes up, then there is no real fallback
kcodyjr: i noticed that problem
kcodyjr: can't even be forcibly reinitialized
kcodyjr: it's a damn good idea that should have come and been embraced long ago. but clearly it's not ready for prime time.
libv: kcodyjr: as someone who has been doing heavy modesetting development his whole graphics driver development career, i am glad to be able to press ctrl-alt-backspace and see a nice vga text mode come back to me
kcodyjr: worse still, an edid read fail will result in a useless screen, and really it's not going to get healthy without full hotplug support on the port itself
kcodyjr: libv, i agree that's the very reason that kms isn't ready for prime time.
kcodyjr: there's no fallbacks. none.
libv: in any case, i never cared where modesetting code lives, kernel, or lowlevel (early) userspace, same difference.
libv: i care about things being done properly and segmented properly
kcodyjr: seems like a good point of view for a hardware driver developer
libv: and i care about not getting things forced upon me where you know many of the reasons why people should do it this way and not another are full of birds
kcodyjr: there are others, though, and one is that the kernel ought to have exclusive direct control of all hardware
kcodyjr: oh, yeah. "reduce startup flickering" is a terrible reason to push kms.
libv: kcodyjr: you may want to ask yourself; why was this kms stuff never done before?
libv: why is it soo important now?
kcodyjr: stability, control, and flexibility, are reasons to overhaul such a major subsystem
libv: what changed in between?
kcodyjr: well, nothing changed. passing-the-buck to userspace by giving direct hardware hooks was a hack from day one, and still is
libv: and if you identified the drivers, are you still so sure that it is going to lead to where you want it to lead?
libv: root should always have the ability to touch the hardware.
KasDra: sorry but with Sorry, but which one of the best 3D acceleration?
kcodyjr: that's got nothing to do with driver models, and everything to do with what kernels are supposed to do. root should have a carefully moderated pathway direct to the hardware, but acceleration functions shouldn't depend on it. only time you'd want root is if you were updating firmware in nvram or something.
libv: kcodyjr: what about touching registers when developing something?
libv: kcodyjr: oh, and guess what, i am kind of involved with flashrom a bit too.
KasDra: sorry, but which one of the best 3D rendering for r5xx cards?
kcodyjr: those quick little hack userspace tools for reading and writing ports are just that, developer aids
kcodyjr: hardware drivers ought to live entirely in the kernel, plain and simple
KasDra: with one is the best?
kcodyjr: so, go right ahead, touch a register - but do it from the kernel
libv: kcodyjr: _entirely_?
libv: kcodyjr: how long have you been following this topic?
kcodyjr: ideally yes. and, quite a number of years i've been lurking.
kcodyjr: i'm well aware of the problems with actually doing it
libv: do you know any other pieces of hardware with the complexity of graphics hardware?
libv: are you aware that even today, many kernel people are extremely weary of graphics drivers in the kernel?
kcodyjr: their implementations or their interfaces?
libv: no matter how much grease redhat and intel try to apply?
kcodyjr: that's because graphics drivers tend to do rude things like access i/o spaces arbitrarily
KasDra: guys, stop fighting
yangman: KasDra: either older fglrx or a recent mesa. 3D isn't handled by the X driver
libv: KasDra: we are not fighting.
kcodyjr: i'm well aware of the arguments. and libv is right, we're not fighting. we're rehasing something that deserves periodic rehashing.
pazof: with my M74 / rv620, which repository should I use ? master ati ?
pazof: radeonhd master ?
libv: kcodyjr: ok, graphics drivers tend to be rude things, why will that be any different when they move from userspace into the kernel?
yangman: pazof: either works
libv: kcodyjr: because most of the time, this is what is implied when people talk about kms.
KasDra: 3D will be handled by kernel mode-setting?
pazof: with 3D ? :)
kcodyjr: it wouldn't. just saying the kernel guys would rather see it in userspcae because they can try to enforce better behavior
libv: everything will be golden then and we will not have any the issues that we have with userspace
kcodyjr: that's bull, we'll have exactly the same problems, because kms -as-implemented- isn't the answer
yangman: pazof: either works ;) what X driver you use isn't supposed to be relevant
pazof: ok ;) thanks
libv: carefully worded of course, so that people read that into it.
libv: kcodyjr: but this is how it is being sold.
libv: kcodyjr: fuzzy wording, and people at the other side then seeing this as the one and only solution to all their problems
kcodyjr: i'm totally not sold on the software project today known as kms. i tried it, liked what it did, but more diskliked what it didn't.
KasDra: 3D will be handled by kernel mode-setting?
kcodyjr: KMS solves nothing except a few peoples' fetish for early initialization
yangman: KasDra: no. you're confusing topics
libv: KasDra: if you put the statements of some people together over time: then yes.
kcodyjr: KasDra, KMS is a highly experimental attempt to make the screen flash and reinitialize less on bootup
libv: kcodyjr: by putting modesetting into the kernel it becomes easier to do some things.
libv: kcodyjr: but it also becomes harder to do some other things.
libv: kcodyjr: but the tricky bits, they remain the same
KasDra: mode-setting is "kernel controling the hardware" so?
libv: and this is the part that people never mention and also don't really want to spend time on
libv: everyone wants to create a bright new future and convince everyone else that this bright new future is just around the corner
kcodyjr: no argument there. but back to where it started, i wasn't endorsing KMS. i was saying hardware drivers belong in the kernel.
libv: but the real problems of today are not solved, and the future is always going to chased
libv: kcodyjr: in general, yes
libv: kcodyjr: but that should not be a hard rule.
libv: kcodyjr: i believe that many usb drivers are in userspace today
kcodyjr: i'm kind of thinking it should. ideally. when ideal is possible.
libv: and usb devices often are very simple compared to graphics
kcodyjr: going through an explicit handler layer is something different. graphics is generally done by handing the addresses down to userspace and being done with it
libv: kcodyjr: X used to work on countless unix like operating systems
libv: and only in this decade did linux grow some pci support that X could be using directly
libv: now most of that is being rapidly cut out
g-zu: wow, libv are back on graphics work?
libv: and the bsds and solarises of this world are being told to shape up or left behind, because X is moving as fast as the linux kernel with its vast developer base (compared to the others)
libv: kcodyjr: now, with kms, this is going to become even worse
libv: kcodyjr: and we are forcing another monopoly to be created
libv: kcodyjr: userspace drivers in X, with the right infrastructure in place, was pretty operating system agnostic
kcodyjr: ok, i'll give you that point
kcodyjr: but on the flip side, a lot of that stuff is legacy, and isn't getting new hardware - solaris and bsds excepted
libv: sure, but we are not helping
libv: just like the graphics card maker situation at this time.
libv: there are only three which count.
kcodyjr: but we do still care about old cards on older boxes, so we shouldn't be breaking existing interfaces, you're right about that
kcodyjr: another truth is, today's graphics hardware is vastly different to drive than yesteryear's. those old interfaces may not be up to it in the end.
libv: and one ignores free software and just does its own thing, the other plays it just so that it can keep its own thing but also not be attacked too much, and the third just sees everything as its own playing ground and despite the massive amount of manpower still is not able to deliver something that its corporate userbase can accept (normal users sadly, are not that important for such companies, even though they too tend to be happier
libv: kcodyjr: well, under xfree86, after 4.2.0 or something happened, driver model evolution stopped.
libv: kcodyjr: these days, we no longer have evolution.
libv: everything gets completely reinvented every time.
kcodyjr: that's what i was driving at.
libv: and the reinvented things always fix the worst of what the previous solution did wrong
libv: but usually also overlooks some of what the previous did right
kcodyjr: but is that the fault of the original model, of the developers, or the hardware czars?
libv: and there is a huge painful transition in between
libv: and kms is yet another example of that
kcodyjr: it is.
kcodyjr: one beef i have with the current incarnation, is that being 90% in userspace as it is, makes it very hard to leverage other system dma engines
libv: current incarnation of what, and for what purpose?
kcodyjr: current incarnation of device drivers, radeonhd included, for stuff like pushing video
libv: well, most graphics devices come with their own dma engines, sometimes we even know or are allowed to use them
kcodyjr: in both directions; both offloading hd frame copies, and pulling streams back from compositor stages
kcodyjr: sure they do, but that's no reason to ignore the one on the mobo
kcodyjr: another thing that's way easier with kernel drivers, is dma remapping, especially if the platform has an iommu
libv: i believe that the situation for radeonhd is the following, if my memory serves; they exist, but we are not allowed to know and use them, in case we break some HDCP or windows vista security model
libv: kcodyjr: i sadly am not clued on that, i have spent too much time doing modesetting and things in a way that users can use it today instead of in the near future to have played with that :)
kcodyjr: actually i was thinking in just the other direction; by putting it all in the kernel, it becomes possible to certify the kernel's trust state
kcodyjr: and, being able to use the mobo dma engines lets us give the vendors the bird, and still have dma engine use, vista security misdesigns or not
libv: there is a reason why people will not mention that as a reason to put graphics drivers in the kernel :p
libv: too many people will be scared by what that sentence at first reading translates to in their heads :)
kcodyjr: using dma engines doesn't translate to making copies of encrypted content.
kcodyjr: if there's encrypted data in that card it can be got out without dma engines
libv: i don't know the exact details on the radeonhd thing there
libv: i just know what bridgman told us about it
kcodyjr: hell, if it comes down to it, hijack the pio ports with a soldering iron and use the indirect registers to force copies to a pci board with a bunch of ram on it
libv: which kind of changes with the wind.
kcodyjr: bet vista wouldn't notice the loss of pio connectivity. and i've read the register specs enough to know, the pio ports are capable of completely controlling the device, albeit slowly
libv: but i think that in this case it could've been used to get more information out of the running the fglrx driver than what ati wants you to have
kcodyjr: ahh. well. imo that's one more argument to use the mobo devices and let them have their secrecy.
libv: but that all is about thresholds. if people really were that stubborn, clued and had that much time, they could find out anything
kcodyjr: as a matter of interest, what do you see getting harder by (generally) moving graphics hardware drivers in-kernel?
agd5f: kcodyjr: the dma engine isn't designed to saturate the bus. the drawing engines are (especially the 3D engine), so they have more bandwidth available for transfers. They perform better and that's why we use the blitter rather than the dma engine for copying data. kms actually has code to move buffers using both the blitter and the dma engine at least for the pre-r6xx chips.
kcodyjr: that's fine, except when you might want the blitter to be doing something only the blitter can do
kcodyjr: for example, i might prefer to use the texture engine for parallel compositing copies that require an image format translation, while simultaneously using a mobo (or card) dma engine to push bytewise copies
agd5f: kcodyjr: the information is available feel free to implement something like that. however, you'll be fighting the blitter for bandwidth, so I'm not sure how much it will help
kcodyjr: i have been tinkering along those lines. nothing serious yet.
kcodyjr: i'm not looking for short paths to anything functional, but i am trying to piece together an environment where a common compositing layer can operate in a non-rgb, non-yuv colorspace
agd5f: also, if you want to use resutls from the 3d engine, you'll have to make sure they've hit memory before you try and copy them using the dma engine
agd5f: probably easiest to use temp buffers depending on what you are doing
kcodyjr: at the moment, in my little tinkering world, i'm trying to conceptualize the hardware from the bottom up - first and foremost a device attached to a bus, secondly has memory which may or may not be discrete but treat it like it is anyway, thirdly has some set of operations it can perform on any memory it can see masking notwithstanding, and only last, has physical hardware to push one or more memory areas to a physical display
kcodyjr: so, i'm planning to go with some kind of page based allocation scheme, so higher level objects can map in and out using the generic dma interface
libv: kcodyjr: you know, it makes sense to just take what's there and try to make sense out of it
kcodyjr: well that's what i mean, i'm trying to look at it in terms of the subsystems the kernel already provides
libv: kcodyjr: seeing clear solutions in code that's there, not theorising about possible solutions, because then you end up reinventing something completely but without getting rid of all the issues
kcodyjr: as usual it could just turn out to be a fun educational experience that leaves me a bunch of ultimately useless code. but it gives me something interesting to do when my wife is monopolizing the television.
kcodyjr: the kernel already does all kinds of that memory stuff for other device drivers, with equally if not higher throughput and latency requirements - disk subsystem for example
kcodyjr: so, in a sense, that's exactly what i'm doing - looking for a solution in existing code
kcodyjr: if i find a combination that works, presumably it could be ported or reinterfaced or whatever, so that massive rewrites aren't required just to get dma engines
agd5f: kcodyjr: what massive rewrites are necessary to use them?
kcodyjr: depends on the case i think; in the 64-bit case, i don't think any. the limiting factor is address visibility.
MostAwesomeDude: Whew, that was quite the scrollback.
MostAwesomeDude: kcodyjr: I'd say the only reason we don't know how to drive the HDCP-related chips on the card is that we're lazy and have better things to do.
kcodyjr: it's a safe assumption that the device can see a 32-bit bus address space, and that 64-bit kernels will map all of the graphics framebuffer to physical
kcodyjr: i wouldn't call dma engines hdcp-related per se MostAwesomeDude
MostAwesomeDude: If I weren't lazy, I'd do the things I need to do. If I weren't lazy and had nothing else to do, I'd write up a kernel hack for a Vista box and dump out an HD video playback session or three.
kcodyjr: besides, i'm not ragging on you for not getting to it yet.
MostAwesomeDude: But the DMA isn't HDCP-related, unlike UVD and AES chips.
kcodyjr: i'm not talking about dma access, i'm talking about dma copy engine offloading
MostAwesomeDude: I didn't think there was a fast DMA engine that beat the blitters in speed.
kcodyjr: doesn't have to beat the blitters in speed to be useful; the blitters might simply have better things to do
MostAwesomeDude: But there's bandwidth issues. You can't always saturate the card.
kcodyjr: true, but the blitter isn't always saturating the bus, nor even its own memory, it caches to hell and gone, does it not?
MostAwesomeDude: Bus saturation shouldn't be your goal.
MostAwesomeDude: You don't saturate your USB or Ethernet links.
kcodyjr: if i've got it doing a 7-simultaneous compositing pass, each with its different image format translation, the blitter just might not have time to accomplish the video stream frame copy
MostAwesomeDude: But those won't be simultaneous, they'll be sequential.
kcodyjr: which puts even more time pressure on the playback frame copy
agd5f: kcodyjr: there's only 1 3d engine
MostAwesomeDude: Even if you're a mad-skillz hacker and you write a fragment program that swizzles four different textures out to four different render targets (which is totally possible on r500 BTW) you're still only writing four colorbuffers at a time.
agd5f: kcodyjr: the pre-r6xx cards only had a 32 bit address space, but you can specify the dma mask in the kernel
kcodyjr: agd5f, yes, that's what i'm getting at. but there is also a dma engine on most motherboards, that, if the graphics card is accessing more cache than bus, the mobo could be pushing the frame into video ram
MostAwesomeDude: And that four-renderbuffer job will take longer than a normal one-renderbuffer job.
MostAwesomeDude: Moreover, this all sounds very specific to a vertically integrated piece of HW.
kcodyjr: vertically integrated?
MostAwesomeDude: Yeah. Specific motherboard chipsets, specific GPUs.
MostAwesomeDude: How would you generalize this?
kcodyjr: seems to me i just described a fairly common constraint
kcodyjr: ahh, that's the real point. i don't have to. the linux kernel has abstractions for mobo dma engines.
agd5f: kcodyjr: this may work if the dma engine is separate from the gpu. but there aren't many mobos yet with dedicated dma engines
kcodyjr: in those cases, i think this could still provide a performance improvement by managing scatter/gather operations, so it becomes a faster operation for the gpu
agd5f: there are already kernel drivers for those that do exist
MostAwesomeDude: Wouldn't this be a completely generic optimization though?
MostAwesomeDude: As in, the kernel driver for that DMA engine will accelerate *all* writes and reads happening to certain memory.
MostAwesomeDude: So we don't need do anything, right?
kcodyjr: correct. i think the most invasive thing would involve memory reservations; either whacking off half for the kernel to allocate from, or actually modifying the drivers to ask the kernel for buffers - that's where it overlaps to kms some. that's all wide open at this point. i'm just looking at making the copies happen in a sane enough way to be useful.
agd5f: kcodyjr: if there is a generic dma engine available, I think memcpy would take advantage of it
kcodyjr: it cannot
kcodyjr: by definition, an engine-driven copy is asynchronous
kcodyjr: blocking while waiting for the completion would probably be worse than just doing the copy with the cpu.
agd5f: there may be an API to use them then
kcodyjr: there is
kcodyjr: but using it meaningfully requires mapping pages back and forth
kcodyjr: especially if you want to take advantage of iommu's, which comes almost free if you're using the scatter/gather api
MostAwesomeDude: kcodyjr: I would imagine that if you wanted async functionality from the DMA engine, there would be a way to ask for it.
MostAwesomeDude: But at some point you *will* have to block for it.
MostAwesomeDude: At that point, you might as well just be using device-specific ioctls to talk to the DMA engine.
kcodyjr: true. but, all the time between that point and the point of issuance, the copy can be in progress, while cpu and gpu are both doing other things
kcodyjr: that seems like it could be handy when you have to deliver 1920x1080x32bpp frames 30 times per second
nha: could be worth the experiments, definitely
kcodyjr: also, the asynchronicity is less of an issue when you're streaming the other way; capturing back from the compositor
MostAwesomeDude: Hm. I kind of doubt that a mobo with a DMA engine would be hosting such an old card.
MostAwesomeDude: Moreover, if you're just looking at reducing bandwidth during video playback, perhaps getting us hooked up to a video-decoding API would be a better usage of time?
kcodyjr: i can see this being useful even on an rv610, assuming a high blitter load... and, any sane video api has to manage getting its buffers back and forth. seems like this is a prereq for that.
MostAwesomeDude: The compositor case is interesting though.
MostAwesomeDude: kcodyjr: Sure, I'm just saying that the buffers would be *smaller* if they were not fully-decoded frames.
kcodyjr: ahh. yes. that. which would reduce the scale of the problem, but not change its nature, really
kcodyjr: but makes itself even more self-critical, if you're now going to tie up the gpu even more doing decode ops
MostAwesomeDude: Not really. A lot of the easy-to-implement stuff is done in shaders.
kcodyjr: easy to implement yes, but it's got to be costly, even if it's cheap
MostAwesomeDude: And there's dedicated blocks on some cards that aren't even being used right now.
MostAwesomeDude: I'd say you save in CPU time what you pay out in GPU time.
kcodyjr: no argument there. but that still doesn't make a background copying engine any less useful
MostAwesomeDude: No, but I'm kind of skeptical that we need any big DMA manager.
MostAwesomeDude: A transparent kernel-side shim to turn it on for large memcpys, and a couple ioctls to request an async transfer, should be fine.
kcodyjr: i'm not even thinking in terms of the userland interface yet.
kcodyjr: quite right that it could be just that simple at that layer
kcodyjr: but it's going to have some unavoidable complexities in the kernel. it's not something that can be set up and forgotten at init time.
MostAwesomeDude: Well, I won't deny that I haven't really read through them, but the kernel-side drivers for these engines *are* there.
kcodyjr: they are. but they are all page-based, and not all of memory can be mapped.
kcodyjr: at least, not in all cases
kcodyjr: if the application wants to guarantee mappability, rather than simply hope for it, it will have to call a purpose-specific allocator... i think
kcodyjr: and part of the kernel-side logic has to deal with graphics adapters that don't make all of their ram visible to the bus
MostAwesomeDude: Um? This is still all kernel-side, right?
kcodyjr: yes. but we were talking about using a userspace-supplied buffer as the source of an engine driven copy.
kcodyjr: if it came from userspace malloc or kernelspace vmalloc, then it's not guaranteed to be mappable on all platforms and all situations
kcodyjr: but there's good odds it might be, so i want to handle that case
MostAwesomeDude: Handle it where?
kcodyjr: if i remember the api correctly, it's a page table lookup
kcodyjr: to make a userspace buffer available to the device, whether it's the mobo dma device or the card itself, means finding its physical location, hoping it's all within the card/engine's visibility, and building a scatter-gather list from all those page table entries
MostAwesomeDude: So which driver does this belong in?
kcodyjr: as applied to the current universe of actual production drivers, this would be an extension to the drm module
kcodyjr: i think.
kcodyjr: once i'm mapping and copying pages in a handful of test cases, i'll figure that out.
kcodyjr: going the other way it's easier; the kernel can request pages from the generic dma subsystem which are guaranteed to be bus-visible, and then there's api's to stuff that into the userspace process's vma list
kcodyjr: hm. there is one obvious stumbling block, though it could be handled most of the time just by adjusting whatever happens next after the data block arrives. bytewise copies always preserve host ordering. does anything modern still run BE? do any of the current radeon drivers actually put the card in BE mode on those platforms?
kcodyjr: and if not, as further query to doing so, since i saw the control in the m72 doc... does that change the endianness of registers as well, or just the linear framebuffer as seen by the chip?
Youngfe: Guys, hello! I'm using Debian AMD64 Squeeze, and now i get the new about 2.6.31 kernel and kms vt support for ATI cards. Please can you tell me if it works on Radeon r500 series?
yangman: what exactly are you asking about?
yangman: KMS? in general?
Youngfe: yangman i read about and discover that it works on my card. Will i need to update my xorg to give support to it? Use this option will be better?
kcodyjr: isn't kms still broken with anything more advanced than shadowfb?
Youngfe: i dont know what is shadowfb
yangman: it works pretty well on r5xx, actually
yangman: Youngfe: see my reply in #radeon. radeonhd doesn't support KMS right now
airlied: kcodyjr: works fully accelerated now.
dandel: hmm... i really wish the suspend on rs780mc was working ><; (any ideas on how i could go about helping to fix this issue?)
yangman: dandel: does it work on radeon?
dandel: goes all the way into desktop with ease on radeonhd driver.
dandel: but when i suspend and then resume, the lcd fails to come back on.
dandel: hmm... interesting radeon log tail i just spoted... why is the rs780mc(hd3100) have avivo_restore in the log.
yangman: radeonhd just doesn't refer to it as avivo
dandel: it's using radeon system module.
yangman: kernel modules logs don't show up in your X log ;)
dandel: kernel log stops at resetting the gpu
dandel: one sec... i'll try installing radeonhd from the software repository, if it exists.
dandel: hmm... weird... radeon at least goes in to suspend, but radeonhd does not.
yangman: so, neither driver work for S/R?
dandel: I'm wondering if the acpi video driver is broken (it did work in 2.6.24 for suspend and resume)
yangman: what radeonhd version?
yangman: 1.2.4 has known S/R bug with r6xx
yangman: so, run >=1.2.5
dandel: although, i have suspend/resume failure without the radeon kernel driver even loaded, which shouldn't happen.
dandel: ok, now it suspends, but video still fails to return upon resume.
dandel: and this is based on the latest radeonhd driver pull.
yangman: can you ssh into the machine and force it on using dpms/
dandel: one sec.
yangman: and grabbing the log would probably be useful
dandel: i already rebooted it
dandel: and it's already logged back in
dandel: hmm... i can't even ssh back in to the machine after the suspend.
dandel: ok, got the xorg log from the last suspend/resume test, and here it is. http://pastbin.com/m36c4bf1f
dandel: ** http://pastebin.com/m36c4bf1f