Re: RFC: output polling + disconnected operation
On Mit, 2010-05-05 at 20:25 +1000, Dave Airlie wrote: > 2010/5/5 Michel Dänzer : > > 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
Re: RFC: output polling + disconnected operation
2010/5/5 Michel Dänzer : > 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. 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, I'd like to advertise the protocol we have now if I can. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
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. -- 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
Re: RFC: output polling + disconnected operation
On Wed, 5 May 2010 11:12:13 +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. It's an ugly problem... When the hotplug event is received, wouldn't you re-probe and find a digital monitor attached? If so, that would mean a mode set sent in by the X server should end up being a full one since the current config is incompatible. Which means X just has to know it forced a mode, so when any event comes in it should re-set the mode unconditionally... Jesse -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
On Wed, May 5, 2010 at 11:37 AM, Jesse Barnes wrote: > On Wed, 5 May 2010 11:12:13 +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. > > It's an ugly problem... When the hotplug event is received, wouldn't > you re-probe and find a digital monitor attached? If so, that would > mean a mode set sent in by the X server should end up being a full one > since the current config is incompatible. Which means X just has to > know it forced a mode, so when any event comes in it should re-set the > mode unconditionally... Userspace (as in gnome/kde/xrandr) doesn't know what is attached, digital or analog, it just sees a connected status, notices it was connected before, it still connected and doesn't do anything. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RFC: output polling + disconnected operation
So one of the problems I want to solve for KMS it the what to do when nothing is plugged in at startup, I've fixed this for fbcon in the current tree, but when looking at X + randr clients I realised it needed a bit more work. I've pulled the polling code back into the core, and it nows can send uevents to userspace when something changes. The drivers can specify flags for each output as to whether it is hotplug capable, needs connection polling and can handle disconnection polling. A lot of outputs can't handle disconnection polling due to DAC polling causing flicker on the current output. Also things like s-video shouldn't be polled for connect or disconnect esp if sharing a dac with a VGA output. So with patch one, we can boot, start X all without anything connected, however it runs into an issue which patch 2 is an attempt to fix. 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? Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
