Heads up: X server configuration changes
 

So you're running an X server? Well, my lad or lass, sit down and let me
tell you about the neverending story of X server input configuration
changes that has hopefully ended now.
I'm just pushing the latest X server goodness into rawhide and enabling
udev, completing (from the X server's POV) the excision of the hardware
abstraction layer that shall not be named.

>From F9 to including F12 (and rawhide until today) we've used hal to
discover the input devices. For lack of better options, this means that many
configurations have moved into fdi files. As you may know, hal is deprecated
and as much as fdi files may be pleasing to the eyes, there's just no future
in them. You'll just have to let it go, even if it hurts.

Instead, we have the newest latest and greatest bits, namely xorg.conf.d
support and InputClasses. You can drop configuration files into the new
directory and the server will pick it up on startup.
e.g. /etc/xorg.conf.d/foobar.conf
"A configuration directory? Is this even possible?" you say? I know, it
sounds mightily advanced but we have to keep surfing the wave of new
technological achievements.

The existing section types in xorg.conf(5) weren't really suitable, so we
now have something that resembles the functionality provided by hal's fdi
files. A section of type InputClass will match against multiple devices and
even hotplugged ones - depending on the match rules. An example section
looks like this:

Section "InputClass"
Identifier "superhero mouse config"
MatchIsPointer "on"
MatchProduct "Mighty Mouse"
Driver "evdev"
Option "X-Ray vision" "on"
EndSection

Any pointer device that contains "Mighty Mouse" in its product name will
match against this section and be added with the evdev driver and the
options as specified. That's just one example, I've tried to detail the new
configurations on our wiki.
https://fedoraproject.org/wiki/Input_device_configuration
If you think there's anything missing, please let me know or add it
yourself.

Because the match rules are different to hal's matching rules, we don't have
an automatic conversion from your custom fdi files into xorg.conf format.
If you have custom rules, I recommend porting them to the new format before
updating to ensure a smooth upgrade.

Cheers,
Peter

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

Hi,

> So you're running an X server? Well, my lad or lass, sit down and let me
> tell you about the neverending story of X server input configuration
> changes that has hopefully ended now.
> I'm just pushing the latest X server goodness into rawhide and enabling
> udev, completing (from the X server's POV) the excision of the hardware
> abstraction layer that shall not be named.
>
> >From F9 to including F12 (and rawhide until today) we've used hal to
>
> discover the input devices. For lack of better options, this means that
> many configurations have moved into fdi files. As you may know, hal is
> deprecated and as much as fdi files may be pleasing to the eyes, there's
> just no future in them. You'll just have to let it go, even if it hurts.
>
> Instead, we have the newest latest and greatest bits, namely xorg.conf.d
> support and InputClasses. You can drop configuration files into the new
> directory and the server will pick it up on startup.
> e.g. /etc/xorg.conf.d/foobar.conf
> "A configuration directory? Is this even possible?" you say? I know, it
> sounds mightily advanced but we have to keep surfing the wave of new
> technological achievements.
>
> The existing section types in xorg.conf(5) weren't really suitable, so we
> now have something that resembles the functionality provided by hal's fdi
> files. A section of type InputClass will match against multiple devices and
> even hotplugged ones - depending on the match rules. An example section
> looks like this:
>
> Section "InputClass"
> Identifier "superhero mouse config"
> MatchIsPointer "on"
> MatchProduct "Mighty Mouse"
> Driver "evdev"
> Option "X-Ray vision" "on"
> EndSection
>
> Any pointer device that contains "Mighty Mouse" in its product name will
> match against this section and be added with the evdev driver and the
> options as specified. That's just one example, I've tried to detail the new
> configurations on our wiki.
> https://fedoraproject.org/wiki/Input_device_configuration
> If you think there's anything missing, please let me know or add it
> yourself.

How is this going to affect some users that don't read release notes nor fedora
devel list? Also, I have some configuration in fdi files (for touchpad for
example). Will it still work with some (not too much visible?) complains in
logs "this is deprecated"? Will it stop working without any information in
logs? ...

> Because the match rules are different to hal's matching rules, we don't
> have an automatic conversion from your custom fdi files into xorg.conf
> format. If you have custom rules, I recommend porting them to the new
> format before updating to ensure a smooth upgrade.
>
> Cheers,
> Peter

Cheers,
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tue, Feb 16, 2010 at 08:25:54AM +0100, Michal Hlavinka wrote:
> Hi,
>
> > So you're running an X server? Well, my lad or lass, sit down and let me
> > tell you about the neverending story of X server input configuration
> > changes that has hopefully ended now.
> > I'm just pushing the latest X server goodness into rawhide and enabling
> > udev, completing (from the X server's POV) the excision of the hardware
> > abstraction layer that shall not be named.
> >
> > >From F9 to including F12 (and rawhide until today) we've used hal to
> >
> > discover the input devices. For lack of better options, this means that
> > many configurations have moved into fdi files. As you may know, hal is
> > deprecated and as much as fdi files may be pleasing to the eyes, there's
> > just no future in them. You'll just have to let it go, even if it hurts.
> >
> > Instead, we have the newest latest and greatest bits, namely xorg.conf.d
> > support and InputClasses. You can drop configuration files into the new
> > directory and the server will pick it up on startup.
> > e.g. /etc/xorg.conf.d/foobar.conf
> > "A configuration directory? Is this even possible?" you say? I know, it
> > sounds mightily advanced but we have to keep surfing the wave of new
> > technological achievements.
> >
> > The existing section types in xorg.conf(5) weren't really suitable, so we
> > now have something that resembles the functionality provided by hal's fdi
> > files. A section of type InputClass will match against multiple devices and
> > even hotplugged ones - depending on the match rules. An example section
> > looks like this:
> >
> > Section "InputClass"
> > Identifier "superhero mouse config"
> > MatchIsPointer "on"
> > MatchProduct "Mighty Mouse"
> > Driver "evdev"
> > Option "X-Ray vision" "on"
> > EndSection
> >
> > Any pointer device that contains "Mighty Mouse" in its product name will
> > match against this section and be added with the evdev driver and the
> > options as specified. That's just one example, I've tried to detail the new
> > configurations on our wiki.
> > https://fedoraproject.org/wiki/Input_device_configuration
> > If you think there's anything missing, please let me know or add it
> > yourself.
>
> How is this going to affect some users that don't read release notes nor fedora
> devel list? Also, I have some configuration in fdi files (for touchpad for
> example). Will it still work with some (not too much visible?) complains in
> logs "this is deprecated"? Will it stop working without any information in
> logs? ...

hmm, at this point, yes, pretty much.
The fdi files are merged in by HAL itself and their content is part of the
information that HAL provides to the server. since the server doesn't listen
to HAL anymore, this information gets ignored.
All you'll see in the log is that it now says "udev" where it used to say
"HAL".

I can put a giant warning into the log that if input devices don't work then
the users should have a look at the website above for reconfiguration. How
does that sound? Do you have any better suggestions?

Cheers,
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On 16.2.2010 08:47, Peter Hutterer wrote:
> I can put a giant warning into the log that if input devices don't work then
> the users should have a look at the website above for reconfiguration. How
> does that sound? Do you have any better suggestions?

Do we have all currently packaged .fdi files converted to The New World
Order™? If no, I guess that's the job for this lowly bugmaster.

Matěj

--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

He uses statistics as a drunken man uses lamp-posts... for
support, rather than illumination.
-- Andrew Lang

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tue, Feb 16, 2010 at 10:54:37AM +0100, Matěj Cepl wrote:
> On 16.2.2010 08:47, Peter Hutterer wrote:
> > I can put a giant warning into the log that if input devices don't work then
> > the users should have a look at the website above for reconfiguration. How
> > does that sound? Do you have any better suggestions?
>
> Do we have all currently packaged .fdi files converted to The New World
> Order™? If no, I guess that's the job for this lowly bugmaster.

evdev and synaptics are updated, so those two are converted. I know fpit has
an fdi file and there's some exceptions in x11-input.fdi that need to be
added too. I need to do this tomorrow unless you want to beat me to it :)

Cheers,
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tuesday 16 February 2010 08:47:20 Peter Hutterer wrote:
> On Tue, Feb 16, 2010 at 08:25:54AM +0100, Michal Hlavinka wrote:
> > Hi,
> >
> > > So you're running an X server? Well, my lad or lass, sit down and let
> > > me tell you about the neverending story of X server input
> > > configuration changes that has hopefully ended now.
> > > I'm just pushing the latest X server goodness into rawhide and enabling
> > > udev, completing (from the X server's POV) the excision of the hardware
> > > abstraction layer that shall not be named.
> > >
> > > >From F9 to including F12 (and rawhide until today) we've used hal to
> > >
> > > discover the input devices. For lack of better options, this means that
> > > many configurations have moved into fdi files. As you may know, hal is
> > > deprecated and as much as fdi files may be pleasing to the eyes,
> > > there's just no future in them. You'll just have to let it go, even if
> > > it hurts.
> > >
> > > Instead, we have the newest latest and greatest bits, namely
> > > xorg.conf.d support and InputClasses. You can drop configuration files
> > > into the new directory and the server will pick it up on startup.
> > > e.g. /etc/xorg.conf.d/foobar.conf
> > > "A configuration directory? Is this even possible?" you say? I know, it
> > > sounds mightily advanced but we have to keep surfing the wave of new
> > > technological achievements.
> > >
> > > The existing section types in xorg.conf(5) weren't really suitable, so
> > > we now have something that resembles the functionality provided by
> > > hal's fdi files. A section of type InputClass will match against
> > > multiple devices and even hotplugged ones - depending on the match
> > > rules. An example section looks like this:
> > >
> > > Section "InputClass"
> > >
> > > Identifier "superhero mouse config"
> > > MatchIsPointer "on"
> > > MatchProduct "Mighty Mouse"
> > > Driver "evdev"
> > > Option "X-Ray vision" "on"
> > >
> > > EndSection
> > >
> > > Any pointer device that contains "Mighty Mouse" in its product name
> > > will match against this section and be added with the evdev driver and
> > > the options as specified. That's just one example, I've tried to
> > > detail the new configurations on our wiki.
> > > https://fedoraproject.org/wiki/Input_device_configuration
> > > If you think there's anything missing, please let me know or add it
> > > yourself.
> >
> > How is this going to affect some users that don't read release notes nor
> > fedora devel list? Also, I have some configuration in fdi files (for
> > touchpad for example). Will it still work with some (not too much
> > visible?) complains in logs "this is deprecated"? Will it stop working
> > without any information in logs? ...
>
> hmm, at this point, yes, pretty much.
> The fdi files are merged in by HAL itself and their content is part of the
> information that HAL provides to the server. since the server doesn't
> listen to HAL anymore, this information gets ignored.
> All you'll see in the log is that it now says "udev" where it used to say
> "HAL".
>
> I can put a giant warning into the log that if input devices don't work
> then the users should have a look at the website above for
> reconfiguration. How does that sound? Do you have any better suggestions?

Are existing *.fdi files going to be used by something (except hal itself)? If
not, hal should be complaining during start up about "deprecated configuration
found".

Also, is this 1:1 change or was something "improved", so we can see changes in
behavior for touchpad or anything else?

>
> Cheers,
> Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote:
> > > > So you're running an X server? Well, my lad or lass, sit down and let
> > > > me tell you about the neverending story of X server input
> > > > configuration changes that has hopefully ended now.
> > > > I'm just pushing the latest X server goodness into rawhide and enabling
> > > > udev, completing (from the X server's POV) the excision of the hardware
> > > > abstraction layer that shall not be named.
> > > >
> > > > >From F9 to including F12 (and rawhide until today) we've used hal to
> > > >
> > > > discover the input devices. For lack of better options, this means that
> > > > many configurations have moved into fdi files. As you may know, hal is
> > > > deprecated and as much as fdi files may be pleasing to the eyes,
> > > > there's just no future in them. You'll just have to let it go, even if
> > > > it hurts.
> > > >
> > > > Instead, we have the newest latest and greatest bits, namely
> > > > xorg.conf.d support and InputClasses. You can drop configuration files
> > > > into the new directory and the server will pick it up on startup.
> > > > e.g. /etc/xorg.conf.d/foobar.conf
> > > > "A configuration directory? Is this even possible?" you say? I know, it
> > > > sounds mightily advanced but we have to keep surfing the wave of new
> > > > technological achievements.
> > > >
> > > > The existing section types in xorg.conf(5) weren't really suitable, so
> > > > we now have something that resembles the functionality provided by
> > > > hal's fdi files. A section of type InputClass will match against
> > > > multiple devices and even hotplugged ones - depending on the match
> > > > rules. An example section looks like this:
> > > >
> > > > Section "InputClass"
> > > >
> > > > Identifier "superhero mouse config"
> > > > MatchIsPointer "on"
> > > > MatchProduct "Mighty Mouse"
> > > > Driver "evdev"
> > > > Option "X-Ray vision" "on"
> > > >
> > > > EndSection
> > > >
> > > > Any pointer device that contains "Mighty Mouse" in its product name
> > > > will match against this section and be added with the evdev driver and
> > > > the options as specified. That's just one example, I've tried to
> > > > detail the new configurations on our wiki.
> > > > https://fedoraproject.org/wiki/Input_device_configuration
> > > > If you think there's anything missing, please let me know or add it
> > > > yourself.
> > >
> > > How is this going to affect some users that don't read release notes nor
> > > fedora devel list? Also, I have some configuration in fdi files (for
> > > touchpad for example). Will it still work with some (not too much
> > > visible?) complains in logs "this is deprecated"? Will it stop working
> > > without any information in logs? ...
> >
> > hmm, at this point, yes, pretty much.
> > The fdi files are merged in by HAL itself and their content is part of the
> > information that HAL provides to the server. since the server doesn't
> > listen to HAL anymore, this information gets ignored.
> > All you'll see in the log is that it now says "udev" where it used to say
> > "HAL".
> >
> > I can put a giant warning into the log that if input devices don't work
> > then the users should have a look at the website above for
> > reconfiguration. How does that sound? Do you have any better suggestions?
>
> Are existing *.fdi files going to be used by something (except hal itself)? If
> not, hal should be complaining during start up about "deprecated configuration
> found".

input.x11_driver and input.x11_options are used only by X, so that'd be an
option.

> Also, is this 1:1 change or was something "improved", so we can see changes in
> behavior for touchpad or anything else?

The problem we had over the last few releases is that we had to resort to
sticking xorg configuration into HAL for lack of an xorg-specific way. this
was bad to begin with but got worse when HAL was deprecated. now we have to
switch to a new config backend (udev) and instead of porting xorg
configuration in HAL format to xorg configuration in udev format, we
implemented an actual xorg-specific way upstream. so now, your xorg-specific
configuration can be in xorg.conf or in /etc/xorg.conf.d/.

so in that way - it's mostly a 1:1 change in functionality, but an
improvement in terms of integration.

neither server nor driver behaviour is affected by this, though, it's simply
a change in how to get the same configuration options into the server.

Cheers,
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
> On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote:
> configuration can be in xorg.conf or in /etc/xorg.conf.d/.

Can it be /etc/X11/xorg.conf.d/ instead please? It would suck to have
to look in two different places, /etc/X11/xorg.conf vs.
/etc/xorg.conf.d/ instead of having everything under one parent
directory. Thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

2010/2/16 Chuck Anderson <cra@wpi.edu>:
> On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
>> On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote:
>> configuration can be in xorg.conf or in /etc/xorg.conf.d/.
>
> Can it be /etc/X11/xorg.conf.d/ instead please? *It would suck to have
> to look in two different places, /etc/X11/xorg.conf vs.
> /etc/xorg.conf.d/ instead of having everything under one parent
> directory. *Thanks.

I hope not. It's pretty fine to have a foo.d folder in /etc and not in
/etc/foo/.

--
LG Thomas

Dubium sapientiae initium
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads up: X server configuration changes
 

On Tue, Feb 16, 2010 at 03:25:24PM +0100, Thomas Janssen wrote:
> 2010/2/16 Chuck Anderson <cra@wpi.edu>:
> > On Tue, Feb 16, 2010 at 09:26:54PM +1000, Peter Hutterer wrote:
> >> On Tue, Feb 16, 2010 at 12:16:42PM +0100, Michal Hlavinka wrote:
> >> configuration can be in xorg.conf or in /etc/xorg.conf.d/.
> >
> > Can it be /etc/X11/xorg.conf.d/ instead please? *It would suck to have
> > to look in two different places, /etc/X11/xorg.conf vs.
> > /etc/xorg.conf.d/ instead of having everything under one parent
> > directory. *Thanks.
>
> I hope not. It's pretty fine to have a foo.d folder in /etc and not in
> /etc/foo/.

Except I didn't recommend /etc/xorg.conf and /etc/xorg.

/etc/X11 is where the X11 config bits live. All I'm saying, is make
the new xorg.conf.d live where all the other X11 config lives.

Why would you want to have the new config:

/etc/xorg.conf.d/*

when the existing config files are:

/etc/X11/xorg.conf
/etc/X11/fontpath.d/*
/etc/X11/xinit/*

Unless you are going to move everything:

/etc/xorg.conf.d/xorg.conf
/etc/xorg.conf.d/fontpath.d/*
/etc/xorg.conf.d/xinit/*
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel