Some days ago Samuli dropped hal USE flag from desktop profiles. I see no problem with it (at least from a gnome packages point of view) but, today, I was noticed by one of the administrators of one of the machines I maintain, that he was no longer able to use keyboard and mouse in that machine. That was caused by that machine running STABLE xorg-server with evdev driver and hal support. On last update, USE flag got disabled, breaking configuration for keyboard and mouse. My suggestion is to simply enable by default hal USE flag for xorg-server-1.7* versions since, if I don't misremember, xorg-server-1.9 will be able to get rid of hal properly without causing problems to our users (and it won't delay hal deprecation that all of us want to reach some day). Thanks a lot Reproducible: Always
(I also CC Samuli to let he know the problem and the suggested solution -> enable hal USE flag by default *only* for xorg-server-1.7* ebuilds)
(In reply to comment #0) > Some days ago Samuli dropped hal USE flag from desktop profiles. I see no > problem with it (at least from a gnome packages point of view) but, today, I > was noticed by one of the administrators of one of the machines I maintain, > that he was no longer able to use keyboard and mouse in that machine. > > That was caused by that machine running STABLE xorg-server with evdev driver > and hal support. On last update, USE flag got disabled, breaking configuration > for keyboard and mouse. > > My suggestion is to simply enable by default hal USE flag for xorg-server-1.7* > versions since, if I don't misremember, xorg-server-1.9 will be able to get rid > of hal properly without causing problems to our users (and it won't delay hal > deprecation that all of us want to reach some day). > > Thanks a lot > > Reproducible: Always > This broke my amd64 system with xorg-server 1.7, no xorg.conf file, and only INPUT_DEVICES="evdev". I had to add "keyboard mouse" to the INPUT_DEVICES and emerge -uavDN world to get the proper drivers in and working properly.
(In reply to comment #0) > Some days ago Samuli dropped hal USE flag from desktop profiles. [snip] > That was caused by that machine running STABLE xorg-server with evdev driver > and hal support. On last update, USE flag got disabled, breaking configuration > for keyboard and mouse. Let me play the devil's advocate here: you rebuilt your whole system (presumably using emerge -DuN world), you didn't pay attention to what you were doing and thus you broke your system. > My suggestion is to simply enable by default hal USE flag for xorg-server-1.7* > versions since, if I don't misremember, xorg-server-1.9 will be able to get rid > of hal properly without causing problems to our users (and it won't delay hal > deprecation that all of us want to reach some day). Let's see it from a different PoV: if we were to enable the hal USE flag by default, *other* users who haven't selected the desktop profile(s) will get it without asking for it. My answer here is no, we will not enable HAL by default. HAL has always been an *optional* part of Xorg. The decision to add it to *and* to remove it from the desktop profile was not ours. If there are issues with how the profile clean-up was handled, Samuli or other people involved should be contacted directly. And as you pointed out, Xorg 1.9 is going stable within a couple days (weeks at most) so forcing yet another useless rebuild just for a default USE flag seems like a bad solution to me. Thanks
(In reply to comment #3) > Let me play the devil's advocate here: you rebuilt your whole system > (presumably using emerge -DuN world), you didn't pay attention to what you were > doing and thus you broke your system. It's not exactly as you summarized: If I were updated that system, I would know what hal USE flag exactly means for xorg-server+evdev and, then, I would enabled it via package.use (since, on the other hand, I would assume the effect of disabling hal for packages like gnome-vfs and so, but not for xorg-server) You cannot assume all people running "emerge -avuDN world" know what exactly hal USE flag means for xorg-server-1.7*, even when the change from defaulting to disabling hal wasn't even noticed. And no, you cannot expect people using their machines for do they jobs know about all hal deprecation history. > > > My suggestion is to simply enable by default hal USE flag for xorg-server-1.7* > > versions since, if I don't misremember, xorg-server-1.9 will be able to get rid > > of hal properly without causing problems to our users (and it won't delay hal > > deprecation that all of us want to reach some day). > > Let's see it from a different PoV: if we were to enable the hal USE flag by > default, *other* users who haven't selected the desktop profile(s) will get it > without asking for it. > > My answer here is no, we will not enable HAL by default. HAL has always been an > *optional* part of Xorg. It's not true as can be read in official xorg guide: http://www.gentoo.org/doc/en/xorg-config.xml#doc_chap3 "By default, Xorg uses HAL (Hardware Abstraction Layer) to detect and configure devices such as keyboards and mice." And a bit bellow the following is highlighted: "Note: Configuring xorg.conf should be seen as a "last resort" option. It really desirable to run without one if possible, and to do all your configuration via HAL policy files. If you still can't get a working configuration, then read on." Then, it seems clear enough to me that HAL is the default for stable xorg-server-1.7* > The decision to add it to *and* to remove it from the > desktop profile was not ours. If there are issues with how the profile clean-up > was handled, Samuli or other people involved should be contacted directly. He is CCed > > And as you pointed out, Xorg 1.9 is going stable within a couple days (weeks at > most) so forcing yet another useless rebuild just for a default USE flag seems > like a bad solution to me. > It's not useless, it simply tries to not keep breaking default configurations using evdev+xorg-server-1.7 > Thanks > Maybe other option that could probably satisfy most of us would be to require "hal" USE flag enabled for old xorg-servers in x11-drivers/xf86-input-evdev RDEPEND
A compromise would be to add =x11-base/xorg-server-1.7* hal to targets/desktop/package.use, so users are not getting hal if they run a non-desktop profile or xorg-server-1.9. If there are no objections, I will commit this later today.
Looks like the best option to me (didn't remember that possibility) :-)
HAL has always been optional, and X.org has always worked fine without it. Users should pay attention if they --newuse world. The "fix" to this is X.org 1.9 stabilization, will get amd64 today.
*one* fix for this is to stabilize 1.9, but a better fix is to also fix this for 1.7
Fixed in CVS. The package.use entry will be dropped (along with xorg-server-1.7) when xorg-server-1.9 is stable.
Thanks :-D