Re: RandR 1.3 additions?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Jan 22, 2008 4:16 AM, Keith Packard <keithp@xxxxxxxxxx> wrote: > > On Tue, 2008-01-22 at 02:04 -0500, Alex Deucher wrote: > > I would argue that connectors > > are a better choice as that's what the user sees. > > Right, I want to at least allow the details of the hardware to be hidden > by default and communicate with the user in terms of visible physical > objects. Exactly. > > > > > the outputs would still handle the detect() functionality, and they > > would choose the encoder. A driver that didn't want to use the > > encoders abstraction would still work so drivers could gradually > > update or not. > > I'm not sure we need anything other than an output property that selects > the desired encoder; is there something extra here? It could be, but it's certainly not as clean. The radeon driver does that now. There are several problems. For one, most users don't even seem to know that output properties exist. Then the setup is different across all drivers, and finally a lot more common state that should be in the server (which actually has the full view) gets pushed into the drivers which have to figure out what exactly the user wants based on verious separate calls. if you have encoders mapped to multiple connectors and the user wants to turn one connector on and the other one off, you have to keep the state straight in the driver which can get complicated as various output entry points get called. I think initially we could just add an encoder struct and some logic to the xserver that the drivers could use or not use. If the driver uses it, then the server would use the logic to do the right thing, otherwise it would fall back to the old behavior. For example, if the driver uses the new encoder stuff, then when a user says turn on VGA-0 and turn off TV-1, the server would know they share an encoder and wouldn't turn it off inadvertently rather than making the driver try to do the right thing. We could initially expose it as an output property, but then add some sort of "official" protocol for it once we sort it out. Alex _______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg
[X Forum] [Devices] [XFree86] [XFree86 Newbie] [Site Home] [IETF Annouce] [Security] [Fontconfig] [Bugtraq] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Video for Linux] [Linux RAID] [Linux Resources]