On Mit, 2010-05-05 at 20:25 +1000, Dave Airlie wrote: > 2010/5/5 Michel Dänzer <mic...@daenzer.net>: > > On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: > >> > >> So at startup X drivers genearlly seem to ask for a list of connectors > >> and status for them, and if it can't find any connected, it goes to > >> unknown, and if none of those they fall over and X exits. Idea 1 was > >> to just pick a connector and claim it is connected when nothing else > >> is, however this falls over, for DVI esp on a dual-DVI card. You pick > >> a DVI connector, claim it is connected, you most likely end up turning > >> on the analog portion of it, you hotplug a digital connector and the > >> uevent gets sent, the client app repolls the connector status, sees > >> the connector is still connected so doesn't do anything. Forcing a > >> disconnect/connect is incredibly racy and hard. So Ben Skeggs > >> suggested we just fake a disconnected connector for this case. It > >> looks a bit messy in xrandr, but from what I can see the gnome client > >> ignores it as it should. > >> > >> Anyways any other ideas on how this might be tackled or improvements > >> that could be made? > > > > If I understand correctly, this tries to address userspace issues (X > > refusing to start up with nothing connected, GNOME doing nothing when an > > output changes from unknown to connected) by making the kernel fake > > information. Wouldn't it be better to address these in userspace? > > Otherwise if more similar issues turn up, we might end up in a twisty > > maze of fake information, possibly with conflicting requirements. > > The thing is current UMS drivers already do bad faking of stuff, > > have a look at the info->first_load_no_devices flags in -ati. > > So if nobody ever thought this was worth doing properly in the first > place or anytime since, I'd like that KMS drivers can just follow what > UMS drivers have done. > > Granted I could probably do the faking in the KMS X.org drivers, but > since UMS drivers never had hotplug or any useful uevent mechanism > they'd never see the problem, so I've fixed the drivers to work.
Doing it in the X drivers would be less ugly IMO, at least the workaround would be in / next to the same component as one of the underlying problems. > My worry with changing X/GNOME is that it'll break some random corner > case assumptions somewhere else in userspace, there are many randr > clients and I don't want to hunt them all down, Then how do you know none of them will trip over this change? > I'd like to advertise the protocol we have now if I can. What protocol are you referring to? To me it would make more sense to address the underlying problems rather than piling up more workarounds. The KMS API should provide as accurate information as possible, not second-guess what its users might expect. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
