Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
updates in 'x', xf86-input-mouse, ...-keyboard?
24 views
Skip to first unread message
Ewald Pfau
May 6, 2012, 8:51:04 PM5/6/12
to
Tried the recent update for Xorg, but found keyboard an mouse not working.
X was frozen.
Logfile said, driver had not been loaded due to version mismatch.
Just looked at the packages files - most everything is new in group 'x',
dating from "Mai 4 21:52", but those two are different:
24564 Mär 20 2011 - x/xf86-input-keyboard-1.6.0-i486-1.txz
45724 Mär 20 2011 - x/xf86-input-mouse-1.7.0-i486-1.txz
(shown in German: Mai is for may, Mär[z] ist for march).
X was frozen.
Logfile said, driver had not been loaded due to version mismatch.
Just looked at the packages files - most everything is new in group 'x',
dating from "Mai 4 21:52", but those two are different:
24564 Mär 20 2011 - x/xf86-input-keyboard-1.6.0-i486-1.txz
45724 Mär 20 2011 - x/xf86-input-mouse-1.7.0-i486-1.txz
(shown in German: Mai is for may, Mär[z] ist for march).
Robby Workman
May 7, 2012, 1:25:06 AM5/7/12
to
On 2012-05-07, Ewald Pfau <ande...@gmx.net> wrote:
> Tried the recent update for Xorg, but found keyboard an mouse not working.
> X was frozen.
> Logfile said, driver had not been loaded due to version mismatch.
>
> Just looked at the packages files - most everything is new in group 'x',
> dating from "Mai 4 21:52", but those two are different:
>
> 24564 Mär 20 2011 - x/xf86-input-keyboard-1.6.0-i486-1.txz
> 45724 Mär 20 2011 - x/xf86-input-mouse-1.7.0-i486-1.txz
A bit of confusion between Pat and me - apologies for that.
> Tried the recent update for Xorg, but found keyboard an mouse not working.
> X was frozen.
> Logfile said, driver had not been loaded due to version mismatch.
>
> Just looked at the packages files - most everything is new in group 'x',
> dating from "Mai 4 21:52", but those two are different:
>
> 24564 Mär 20 2011 - x/xf86-input-keyboard-1.6.0-i486-1.txz
> 45724 Mär 20 2011 - x/xf86-input-mouse-1.7.0-i486-1.txz
My intent was for those two to be removed - I figured that everyone
was using input hotplugging and the evdev driver by now, and as such,
those two would no longer be needed. As it turns out, there are still
quite a few stubborn people who have input hotplugging disabled. On
its own, that's fine, and there's no problem.
Enter the xorg-server upgrade, and note that the last several releases
of it changed the ABI. Therefore, all xorg drivers (xf86-{input,video}-*)
must be recompiled to match the ABI.
Since I intended for those two to be removed, I didn't increment the
build numbers, so they weren't rebuilt. Pat wasn't sure if the best
option was removing them, so he left them alone for now.
Since there are new releases of both of them on the xorg mirrors,
you can almost surely expect two things:
1) xf86-input-keyboard and xf86-input-mouse will remain in the tree
2) both of them will be upgraded in the next public push
In the meantime, rebuild both of them and you can get back up and
running:
# cd $slackware_source_dir/x/x11/
# BUILD=1_some_unique_id sh x11.SlackBuild driver xf86-input-keyboard
# BUILD=1_some_unique_id sh x11.SlackBuild driver xf86-input-mouse
# upgradepkg /tmp/x11-build/xf86-input-{keyboard,mouse}-*.t?z
-RW
Ewald Pfau
May 7, 2012, 2:30:18 PM5/7/12
to
Robby Workman <newsg...@rlworkman.net>:
> My intent was for those two to be removed - I figured that everyone
> was using input hotplugging and the evdev driver by now, and as such,
> those two would no longer be needed. As it turns out, there are still
> quite a few stubborn people who have input hotplugging disabled. On
> its own, that's fine, and there's no problem.
I see. Years go by. ;)
In fact, when autodetect arrived some time ago, I would not manage to keep
the keys-rate at 250/30, so I used some interactive tool for this, each time
I started X - and switched back to no-autodetect, as soon as this option
returned.
As a side-effect, there is no need for having hald running, as I understand,
this way, with small window managers. So I felt comfortable, not to give too
many demons reason for running. But ok, I left hald running, anyway.
> Enter the xorg-server upgrade, and note that the last several releases
> of it changed the ABI. Therefore, all xorg drivers (xf86-{input,video}-*)
> must be recompiled to match the ABI.
Thank you for hints and insight.
I took an empty partition now, for to give it a try on its own.
After a fresh, new installation I just started up X. So what: It works out
of the pocket, without touching anything for configuration! There's no need
for a xorg.conf file at all, now.
Then there is xorgsetup, to provide a version of xorg.conf - it leaves input
as autodetect, and everything works.
But anyway, I inserted the source files for xf86-input drivers, to give it a
try.
> Since I intended for those two to be removed, I didn't increment the
> build numbers, so they weren't rebuilt. Pat wasn't sure if the best
> option was removing them, so he left them alone for now.
>
> Since there are new releases of both of them on the xorg mirrors,
> you can almost surely expect two things:
I found a newer 1.7.2 as mouse driver, but there is still 1.6.0 for the
keyboard (in fact, it is a laptop with the lid closed, and everything is
detected, 2 keyboards and 3 mice, there is no problem with this, as
indicated, when looking-up the logfiles).
After compilation via building a package (and the appropriate ABI class is
inherited from the already installed version of X), as you suggested ... it
still doesn't work!
For mouse driver, which has been updated, X.0.log says:
[ 982.327] (II) Using input driver 'mouse' for 'Mouse0'
[ 982.327] (**) Option "CorePointer"
[ 982.327] (**) Mouse0: always reports core events
[ 982.327] (**) Option "Protocol" "auto"
[ 982.327] (**) Option "Device" "/dev/input/mice"
[ 982.327] (II) Mouse0: Setting mouse protocol to "ExplorerPS/2"
[ 982.327] (**) Mouse0: Protocol: "auto"
[ 982.327] (**) Mouse0: always reports core events
So this looks much better.
But for kbd driver, for which I did not see a newer version, X.0.log says:
[ 982.620] (II) Using input driver 'kbd' for 'Keyboard0'
[ 982.620] (**) Option "CoreKeyboard"
[ 982.620] (**) Keyboard0: always reports core events
and there it sits, frozen at this position (log file ends here, I waited
some minutes before forced reboot, so it sync'd in the background), in a
situation, where the screen is black.
As indicated, autodetect is that much more stable than it was quite some
time ago, and kbdrate 250/30 looks like being detected (or at least not
being changed to 500/30 as it was before; reading of configuration statement
in xorg.conf worked all the time, but configuration in the keymap file in
/etc/hal/fdi/policy would not work).
So maybe for the moment, input from xorg might not be that clear, either, in
this regards.
From a straight system view, it seems a bit strange to me, to depend on a
running demon just for keyboard input to work at all. But from application
view, ok, hardly anyone will care about what is running in the background,
if it just works fine. Fallback would be nice, though.
> My intent was for those two to be removed - I figured that everyone
> was using input hotplugging and the evdev driver by now, and as such,
> those two would no longer be needed. As it turns out, there are still
> quite a few stubborn people who have input hotplugging disabled. On
> its own, that's fine, and there's no problem.
In fact, when autodetect arrived some time ago, I would not manage to keep
the keys-rate at 250/30, so I used some interactive tool for this, each time
I started X - and switched back to no-autodetect, as soon as this option
returned.
As a side-effect, there is no need for having hald running, as I understand,
this way, with small window managers. So I felt comfortable, not to give too
many demons reason for running. But ok, I left hald running, anyway.
> Enter the xorg-server upgrade, and note that the last several releases
> of it changed the ABI. Therefore, all xorg drivers (xf86-{input,video}-*)
> must be recompiled to match the ABI.
I took an empty partition now, for to give it a try on its own.
After a fresh, new installation I just started up X. So what: It works out
of the pocket, without touching anything for configuration! There's no need
for a xorg.conf file at all, now.
Then there is xorgsetup, to provide a version of xorg.conf - it leaves input
as autodetect, and everything works.
But anyway, I inserted the source files for xf86-input drivers, to give it a
try.
> Since I intended for those two to be removed, I didn't increment the
> build numbers, so they weren't rebuilt. Pat wasn't sure if the best
> option was removing them, so he left them alone for now.
>
> Since there are new releases of both of them on the xorg mirrors,
> you can almost surely expect two things:
keyboard (in fact, it is a laptop with the lid closed, and everything is
detected, 2 keyboards and 3 mice, there is no problem with this, as
indicated, when looking-up the logfiles).
After compilation via building a package (and the appropriate ABI class is
inherited from the already installed version of X), as you suggested ... it
still doesn't work!
For mouse driver, which has been updated, X.0.log says:
[ 982.327] (II) Using input driver 'mouse' for 'Mouse0'
[ 982.327] (**) Option "CorePointer"
[ 982.327] (**) Mouse0: always reports core events
[ 982.327] (**) Option "Protocol" "auto"
[ 982.327] (**) Option "Device" "/dev/input/mice"
[ 982.327] (II) Mouse0: Setting mouse protocol to "ExplorerPS/2"
[ 982.327] (**) Mouse0: Protocol: "auto"
[ 982.327] (**) Mouse0: always reports core events
So this looks much better.
But for kbd driver, for which I did not see a newer version, X.0.log says:
[ 982.620] (II) Using input driver 'kbd' for 'Keyboard0'
[ 982.620] (**) Option "CoreKeyboard"
[ 982.620] (**) Keyboard0: always reports core events
and there it sits, frozen at this position (log file ends here, I waited
some minutes before forced reboot, so it sync'd in the background), in a
situation, where the screen is black.
As indicated, autodetect is that much more stable than it was quite some
time ago, and kbdrate 250/30 looks like being detected (or at least not
being changed to 500/30 as it was before; reading of configuration statement
in xorg.conf worked all the time, but configuration in the keymap file in
/etc/hal/fdi/policy would not work).
So maybe for the moment, input from xorg might not be that clear, either, in
this regards.
From a straight system view, it seems a bit strange to me, to depend on a
running demon just for keyboard input to work at all. But from application
view, ok, hardly anyone will care about what is running in the background,
if it just works fine. Fallback would be nice, though.
Robby Workman
May 8, 2012, 12:29:13 AM5/8/12
to
On 2012-05-07, Ewald Pfau <ande...@gmx.net> wrote:
> Robby Workman <newsg...@rlworkman.net>:
>
>> My intent was for those two to be removed - I figured that everyone
>> was using input hotplugging and the evdev driver by now, and as such,
>> those two would no longer be needed. As it turns out, there are still
>> quite a few stubborn people who have input hotplugging disabled. On
>> its own, that's fine, and there's no problem.
>
> I see. Years go by. ;)
Indeed they do :D
>
>> My intent was for those two to be removed - I figured that everyone
>> was using input hotplugging and the evdev driver by now, and as such,
>> those two would no longer be needed. As it turns out, there are still
>> quite a few stubborn people who have input hotplugging disabled. On
>> its own, that's fine, and there's no problem.
>
> I see. Years go by. ;)
> In fact, when autodetect arrived some time ago, I would not manage to keep
> the keys-rate at 250/30, so I used some interactive tool for this, each time
> I started X - and switched back to no-autodetect, as soon as this option
> returned.
>
> As a side-effect, there is no need for having hald running, as I understand,
> this way, with small window managers. So I felt comfortable, not to give too
> many demons reason for running. But ok, I left hald running, anyway.
HAL will be removed - nothing else will be using it.
>> Enter the xorg-server upgrade, and note that the last several releases
>> of it changed the ABI. Therefore, all xorg drivers (xf86-{input,video}-*)
>> must be recompiled to match the ABI.
>
> Thank you for hints and insight.
>
> I took an empty partition now, for to give it a try on its own.
>
> After a fresh, new installation I just started up X. So what: It works out
> of the pocket, without touching anything for configuration! There's no need
> for a xorg.conf file at all, now.
> Then there is xorgsetup, to provide a version of xorg.conf - it leaves input
> as autodetect, and everything works.
config snippets in /usr/share/X11/xorg.conf.d/ in CHANGES_AND_HINTS.TXT
at some point.
> But anyway, I inserted the source files for xf86-input drivers, to give it a
> try.
>
>> Since I intended for those two to be removed, I didn't increment the
>> build numbers, so they weren't rebuilt. Pat wasn't sure if the best
>> option was removing them, so he left them alone for now.
>>
>> Since there are new releases of both of them on the xorg mirrors,
>> you can almost surely expect two things:
>
> I found a newer 1.7.2 as mouse driver, but there is still 1.6.0 for the
> keyboard (in fact, it is a laptop with the lid closed, and everything is
> detected, 2 keyboards and 3 mice, there is no problem with this, as
> indicated, when looking-up the logfiles).
> After compilation via building a package (and the appropriate ABI class is
> inherited from the already installed version of X), as you suggested ... it
> still doesn't work!
>
> For mouse driver, which has been updated, X.0.log says:
>
> [ 982.327] (II) Using input driver 'mouse' for 'Mouse0'
> [ 982.327] (**) Option "CorePointer"
> [ 982.327] (**) Mouse0: always reports core events
> [ 982.327] (**) Option "Protocol" "auto"
> [ 982.327] (**) Option "Device" "/dev/input/mice"
> [ 982.327] (II) Mouse0: Setting mouse protocol to "ExplorerPS/2"
> [ 982.327] (**) Mouse0: Protocol: "auto"
> [ 982.327] (**) Mouse0: always reports core events
>
> So this looks much better.
>
> But for kbd driver, for which I did not see a newer version, X.0.log says:
>
> [ 982.620] (II) Using input driver 'kbd' for 'Keyboard0'
> [ 982.620] (**) Option "CoreKeyboard"
> [ 982.620] (**) Keyboard0: always reports core events
>
> and there it sits, frozen at this position (log file ends here, I waited
> some minutes before forced reboot, so it sync'd in the background), in a
> situation, where the screen is black.
from trying to use the keyboard (as if one wasn't there at all), I think
you have to have one or more of these options in an xorg.conf(.d/snippet):
"ServerFlags" section to disable input device hotplugging:
Option "AllowEmptyInput" "false"
Option "AutoAddDevices" "false"
Option "AutoEnableDevices" "false"
> As indicated, autodetect is that much more stable than it was quite some
> time ago, and kbdrate 250/30 looks like being detected (or at least not
> being changed to 500/30 as it was before; reading of configuration statement
> in xorg.conf worked all the time, but configuration in the keymap file in
> /etc/hal/fdi/policy would not work).
>
> So maybe for the moment, input from xorg might not be that clear, either, in
> this regards.
See /usr/share/X11/xorg.conf.d/ contents for details.
> From a straight system view, it seems a bit strange to me, to depend on a
> running demon just for keyboard input to work at all. But from application
> view, ok, hardly anyone will care about what is running in the background,
> if it just works fine. Fallback would be nice, though.
included - they're alternatives to evdev if you don't care about input
hotplugging (but to be clear, I think everyone should use evdev).
-RW
Ewald Pfau
May 10, 2012, 6:11:15 PM5/10/12
to
Robby Workman <newsg...@rlworkman.net>:
> I think that's the goal of having the xf86-input-{keyboard,mouse} drivers
> included - they're alternatives to evdev if you don't care about input
> hotplugging (but to be clear, I think everyone should use evdev).
For the report: Everything ist fine again, works with both input versions.
Thank you and PV for the effort.
Btw., keyboard reaction has improved, feels more immediate, and there has
gone some funny post-reaction, so the queue after a keyboard repeat would
empty its last character about half second too late.
Btw2, looks like I keep with GNUStep / Windowmaker, as XFCE does not lend me
really all of the real estate on screen, as I want it perfectly empty (ok,
KDE 3.5 allowed this as well; XFCE insists on a small row of pixels, at
least). For launching and navigating there is already enough redandancy,
even without icons & reminders & etc permanently visible - distracting.
Might be somehow, like all the time listening to music which has no meaning
other than a carpet. I don't: Perfect silence is best. Same on the screen:
It's silent, applications are waiting without generating noise to remind
that they exist. Just a little note from a planet of other minorities.
> I think that's the goal of having the xf86-input-{keyboard,mouse} drivers
> included - they're alternatives to evdev if you don't care about input
> hotplugging (but to be clear, I think everyone should use evdev).
Thank you and PV for the effort.
Btw., keyboard reaction has improved, feels more immediate, and there has
gone some funny post-reaction, so the queue after a keyboard repeat would
empty its last character about half second too late.
Btw2, looks like I keep with GNUStep / Windowmaker, as XFCE does not lend me
really all of the real estate on screen, as I want it perfectly empty (ok,
KDE 3.5 allowed this as well; XFCE insists on a small row of pixels, at
least). For launching and navigating there is already enough redandancy,
even without icons & reminders & etc permanently visible - distracting.
Might be somehow, like all the time listening to music which has no meaning
other than a carpet. I don't: Perfect silence is best. Same on the screen:
It's silent, applications are waiting without generating noise to remind
that they exist. Just a little note from a planet of other minorities.
Ewald Pfau
May 17, 2012, 8:50:54 PM5/17/12
to
myself <ande...@gmx.net> the other day:
[keyboard via evdev or via kbd driver]
an usb-keyboard:
Having set options, for evdev driver in </etc/X11/xorg.conf.d>, the
statement for key repeat-rate is forgotten and not reloaded, when
usb-keyboard is detached and later-on re-attached.
****
--- /etc/X11/xorg.conf.d/90-keyboard-layout.conf ----
# file copied from /usr/share/X11/xorg.conf.d and modified
Section "InputClass"
Identifier "keyboard-all"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "AutoRepeat" "250 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl,de,fr"
Option "XkbOptions" "lv3:ralt_switch"
Option "XkbOptions" "lv5:rwin_switch"
Option "XkbOptions" "grp:lwin_switch"
EndSection
--------------------------------------------------------
****
When having instead the kbd driver, with those lines in xorg.conf
(which are commented out for the above situation):
----------------------------
Section "ServerFlags"
Option "AutoAddDevices" "false"
Option "AllowEmptyInput" "false"
Option "AutoEnableDevices" "false"
EndSection
----------------------------
plus the lines (which are just igonored in the other situation):
----------------------------
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "AutoRepeat" "250 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl,de,fr"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "XkbOptions" "lv3:ralt_switch"
EndSection
----------------------------
so Autorepeat is stable, that is, the setting "250 30" survives unplugging
and replugging.
Just to hand over the observation.
[keyboard via evdev or via kbd driver]
> For the report: Everything ist fine again, works with both input versions.
> Thank you and PV for the effort.
Addition once more, for this topic, now regarding unplugging and replugging
> Thank you and PV for the effort.
an usb-keyboard:
Having set options, for evdev driver in </etc/X11/xorg.conf.d>, the
statement for key repeat-rate is forgotten and not reloaded, when
usb-keyboard is detached and later-on re-attached.
****
--- /etc/X11/xorg.conf.d/90-keyboard-layout.conf ----
# file copied from /usr/share/X11/xorg.conf.d and modified
Section "InputClass"
Identifier "keyboard-all"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "AutoRepeat" "250 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl,de,fr"
Option "XkbOptions" "lv3:ralt_switch"
Option "XkbOptions" "lv5:rwin_switch"
Option "XkbOptions" "grp:lwin_switch"
EndSection
--------------------------------------------------------
****
When having instead the kbd driver, with those lines in xorg.conf
(which are commented out for the above situation):
----------------------------
Section "ServerFlags"
Option "AutoAddDevices" "false"
Option "AllowEmptyInput" "false"
Option "AutoEnableDevices" "false"
EndSection
----------------------------
plus the lines (which are just igonored in the other situation):
----------------------------
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "AutoRepeat" "250 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us_intl,de,fr"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
Option "XkbOptions" "lv3:ralt_switch"
EndSection
----------------------------
so Autorepeat is stable, that is, the setting "250 30" survives unplugging
and replugging.
Just to hand over the observation.
0 new messages