Hal and Xorg output devices

Ely Levy elylevy-xserver at cs.huji.ac.il
Thu Feb 24 08:59:09 PST 2005


On Wed, 23 Feb 2005, Jon Smirl wrote:

> On Wed, 23 Feb 2005 19:53:32 +0200 (IST), Ely Levy
> <elylevy at cs.huji.ac.il> wrote:
> > I was wondering about that as well, I guess it depends if we are going
> > to completly move to xgl or just give it as another option.
> > What do you mean by lower level?in kernel space?I don't think that would
> > be wise especialy if we want to have long exeption list.
> > does it have to happen in lower level?Maybe it should be like hotplug
> > or udev?
>
> The current plan for mode setting is to use a root priv helper app to
> generate the list of legal modes. The list can come from DDC or a /etc
> file. The list is then set into the fbdev driver via a sysfs
> attribute, modes, which only root can write. Running the app for
> generating the list is trigger via a hotplug event when the module is
> loaded or if the hardware supports it, an interrupt generated by a
> monitor switch (radeon has this).

What's wrong with using hal then?

> Another sysfs variable, mode, is then used to set the mode. Ownership
> of mode is assigned via pam at login to the active user. Take one of
> the mode names from the list in 'modes' and copy it to 'mode' that
> will allow you to set modes without the need to be root. This is a
> major step in removing the need for X to run as root. Since the list
> is constrainted you can't set a mode that will blow up your monitor as
> a normal user.
>
> If anyone wants to work on the base layers of XGL, we can use all the
> help we can get.

sysfs sounds very os depended,
I think we should do it from hal who would manage those things
if needed it can made to use pam as well or use some other permission
handling way (should probebly discussed with hal people)
this way both xgl and any other x server who supports hal
can use it.

> --
> Jon Smirl
> jonsmirl at gmail.com
>

Ely



More information about the xorg mailing list