On Tue, Jul 13, 2010 at 11:11:17 -0400, Stephen Powell wrote: > Cyril Brulebois wrote: > > Care to share a reference to the bug you reported? > Ben Hutchings wrote: > > I assume you've filed a bug requesting support for custom modes, as > > requested by the X maintainers? > > As Sven Joachim has pointed out, this would be an exercise in futility. > Upstream deliberately removed support for UMS a while ago. From their point > of view, this is not a bug, this is a "feature". And that's why I use the > nv driver. Is KMS supposed to work with custom video modes? Is the nouveau Depends what you mean by 'custom'. It can use cvt/gtf modes, IIRC. > driver supposed to work with custom video modes? If so, then Yes. > perhaps it would be worthwhile to file a bug report. Otherwise, it's a > waste of time. > > Stephen Powell wrote: > > The intel driver supports both KMS and UMS. > > Cyril Brulebois wrote: > > That's no longer correct. http://ikibiki.org/blog/2010/07/04/We_need_you_redux/ > > Ben Hutchings wrote: > > Not any more. > > As of xserver-xorg-video-intel 2:2.9.1-4, which is current in Squeeze, > and for the i915G chipset, I can still pass > > modeset=0 > > to the i915 module and the X driver will still work. Are you saying that > this is going to be taken away from me too? Oh joy! > Yes, that will go away. We might keep UMS in squeeze for 8xx chips that don't work correctly with KMS at this point, but for anything else UMS is as good as dead. > Ben Hutchings wrote: > > Because UMS is a nasty hack that makes various features impossible, and > > it is too much work to maintain both models. > > I'm beginning to see what I'm up against. > I'm not trying to stand in the way of progress. I wish I could, however, > stand in the way of regress. When you take away features that used to > work and now don't anymore, that's not progress. Whether the actual > mode setting takes place in kernel space or in user space is not my > issue. I see the advantages of doing it in kernel space. The problem is > two-fold, as I see it. (1) The kernel wants to set the mode once and > leave it there, including when switching to a "text" console. It doesn't > switch the card into a true hardware text mode. (2) It appears to me that > the kernel (or video driver) may only support video modes that can be set > by the video BIOS. Correct me if I'm wrong. (It wouldn't be the first > time!) But no-one is listening. And if I stand in the way of regress, > I'll get run over. (Sigh.) > You're wrong. A firmware driver such as vesa only supports modes that can be set by the bios. A native driver can set pretty much arbitrary modes. And KMS provides a fbdev interface so you can change modes with fbset on the console. Cheers, Julien
Attachment:
signature.asc
Description: Digital signature