Call for Testing: Xorg Updates (20100830)

grissiom · 11-06-2010, 07:29 AM

@rworkman

Sorry that I am wrong ;( The EE in log was caused by missing MatchDevicePath "/dev/input/event*" in conf... Now I got to know that stuff in /etc/X11/xorg.conf.d will *overwrite* stuff in /usr/share/X11/xorg.conf.d.(zsd and the bug report thread misled me so much...) All the thing goes right here now

Thanks!

Didier Spaier · 11-06-2010, 06:44 PM

Quote:

Originally Posted by rworkman

That's done by input_id (part of udev). Is there a button or something on that mouse, which would make it have a "keyboard" of sorts? More importantly, does it work correctly regardless? If not, then this is worth posting on the udev mailing list -- input_id.c hasn't been touched since January, so it's not likely to be fixed by upgrading udev.

In fact in Xorg.0.log the line:

Code:

(II) XINPUT: Adding extended input device "HP Laser Mobile Mouse" (type: KEYBOARD)

is an output of xf86Xinput.c included in xorg-server and the type (KEYBOARD in that case) is passed to the server by the input driver (xf86-input-evdev, file evdev.c).

The lines:

Code:

(II) HP Laser Mobile Mouse: Configuring as mouse
(II) HP Laser Mobile Mouse: Configuring as keyboard

are outputs of evdev.c

It seems that evdev.c consider my mouse as both:
- a mouse, because it passes the test (has_rel_axes || has_abs_axes || num_buttons) and is neither a touchpad nor a tablet
- a keyboard, because it passes the test (has keys), maybe because it has a "special" button on top whose purpose is to change the scrolling mode.

Maybe only one type (attribute type_name) is passed to xf86Xinput.c by evdev.c, which could explain that xf86Xinput.c consider the device only as a keyboard.

I can't check because of my _very_near_to_zero_ ability to understand the source code.

As a side note I understand now that it's not that easy to define an input device's type(s)-- a good ontology is probably hard to establish, especially as new pointer types could appear in the future.

Anyway everything works as expected, so case closed on my side

I apologize for the noise and thank you very much for your help.

I append my last X log (mouse already plugged-in at startup) as well as xf86-input-evdev-2.5.0/src/evdev.c and xorg-server-1.9.2/hw/xfree86/commonxf86Xinput.c.

grissiom · 11-06-2010, 08:15 PM

I don't know whether it's relative to Didier Spaier's issue but

Code:

[  4327.960] (**) Laptop_Integrated_Webcam_2M: Applying InputClass "evdev keyboard catchall"
[  4327.960] (**) Laptop_Integrated_Webcam_2M: Applying InputClass "keyboard-all"
[  4327.960] (**) Laptop_Integrated_Webcam_2M: always reports core events
[  4327.960] (**) Laptop_Integrated_Webcam_2M: Device: "/dev/input/event11"
[  4327.967] (--) Laptop_Integrated_Webcam_2M: Found keys
[  4327.967] (II) Laptop_Integrated_Webcam_2M: Configuring as keyboard
[  4327.967] (II) XINPUT: Adding extended input device "Laptop_Integrated_Webcam_2M" (type: KEYBOARD)
[  4327.967] (**) Option "xkb_rules" "evdev"
[  4327.967] (**) Option "xkb_model" "evdev"
[  4327.967] (**) Option "xkb_layout" "us"
[  4327.967] (**) Option "xkb_options" "terminate:ctrl_alt_bksp"

It seems X treat my webcam as a keyboard... However, I can see my face in Kopete.

rworkman · 11-06-2010, 09:06 PM

Quote:

Originally Posted by Didier Spaier

In fact in Xorg.0.log the line:

Code:

(II) XINPUT: Adding extended input device "HP Laser Mobile Mouse" (type: KEYBOARD)

is an output of xf86Xinput.c included in xorg-server and the type (KEYBOARD in that case) is passed to the server by the input driver (xf86-input-evdev, file evdev.c).

The lines:

Code:

(II) HP Laser Mobile Mouse: Configuring as mouse
(II) HP Laser Mobile Mouse: Configuring as keyboard

are outputs of evdev.c

It seems that evdev.c consider my mouse as both:
- a mouse, because it passes the test (has_rel_axes || has_abs_axes || num_buttons) and is neither a touchpad nor a tablet
- a keyboard, because it passes the test (has keys), maybe because it has a "special" button on top whose purpose is to change the scrolling mode.

Maybe only one type (attribute type_name) is passed to xf86Xinput.c by evdev.c, which could explain that xf86Xinput.c consider the device only as a keyboard.

I can't check because of my _very_near_to_zero_ ability to understand the source code.

As a side note I understand now that it's not that easy to define an input device's type(s)-- a good ontology is probably hard to establish, especially as new pointer types could appear in the future.

Agreed, but I'm pretty sure all that comes from ./config/udev.c in xorg-server source - have a look

Quote:

Anyway everything works as expected, so case closed on my side

All's well that ends well.

zsd · 11-07-2010, 10:44 AM

Robbie,

synaptics 1.3.0 and xorg 1.9.2 are cooperating nicely on this tablet.
Thanks for your efforts.

Having said that, any chance of you compiling in the gesture extension?

Thanks.

rworkman · 11-07-2010, 12:04 PM

Quote:

Originally Posted by zsd

Robbie,

synaptics 1.3.0 and xorg 1.9.2 are cooperating nicely on this tablet.
Thanks for your efforts.

Having said that, any chance of you compiling in the gesture extension?

As I've told someone else earlier in this thread, this "gesture" stuff appears to be proprietary (the synaptics company website mentions it), and even if it isn't, there's nothing in the xf86-input-synaptics configure script relating to it. To summarize my thoughts on it:
1) I don't think it's possible
2) If it is possible, someone else is going to have to figure it out and tell me
3) If (2) is accomplished, it will have to be done in such a way that no patent issues arise

zsd · 11-09-2010, 09:55 AM

Quote:

Originally Posted by rworkman

As I've told someone else earlier in this thread, this "gesture" stuff appears to be proprietary (the synaptics company website mentions it), and even if it isn't, there's nothing in the xf86-input-synaptics configure script relating to it. To summarize my thoughts on it:
1) I don't think it's possible
2) If it is possible, someone else is going to have to figure it out and tell me
3) If (2) is accomplished, it will have to be done in such a way that no patent issues arise

As I mentioned (maybe not loudly enough) in message # 166, I'm *not* talking about the synaptics stuff. I'm talking about generic gesture recognition for multi-touch devices such as touch screens. However, after looking around a bit, I see that Ubuntu's implementation is still in draft stage, which may explain why you don't see it. (Or maybe you were looking in "synpatics" when somewhere else was the place to look.) Assuming it hasn't made it into xorg 1.9.2, I suppose I'm asking about this months too early.

For anyone interested, there is a thread about it here:
http://lists.x.org/archives/xorg-dev...st/012036.html

In particular, in
http://lists.x.org/archives/xorg-dev...st/012037.html
I see the following:
The XInput protocol through version 2.0 supports single touch input devices. Beginning with version 2.1, XInput will support multitouch input devices.

I guess I'll leave that for your consideration as to whether this is too far out in the future for you to worry about. I'll go back to trying to get my Wacom to work :-(

imitheos · 11-11-2010, 01:04 PM

Quote:

Originally Posted by Didier Spaier

It seems that evdev.c consider my mouse as both:
- a mouse, because it passes the test (has_rel_axes || has_abs_axes || num_buttons) and is neither a touchpad nor a tablet
- a keyboard, because it passes the test (has keys), maybe because it has a "special" button on top whose purpose is to change the scrolling mode.

Most of the time this is harmless. Many mice register two event devices
(and many keyboards register one event device for normal keys and one for
multimedia keys).

For example, my Logitech MX1100R Mouse shows:

Code:

# cat /proc/bus/input/devices
I: Bus=0003 Vendor=046d Product=c526 Version=0111
N: Name="Logitech USB Receiver"
H: Handlers=mouse0 event2 

I: Bus=0003 Vendor=046d Product=c526 Version=0111
N: Name="Logitech USB Receiver"
H: Handlers=kbd event3

sahko · 11-13-2010, 05:22 PM

While the out of tree packages arent updated anymore theres an X11R7.6 RC 1 announcement
http://lists.freedesktop.org/archive...er/051792.html

rworkman · 11-14-2010, 11:55 PM

Okay, as everyone should have noticed by now, this has all hit the -current (development) tree. You'll need to remove the talloc package before upgrading - rather than split talloc into a separate package, Pat elected to put the library in aaa_elflibs.

Didier Spaier · 11-15-2010, 12:20 AM

Quote:

Originally Posted by rworkman

Okay, as everyone should have noticed by now, this has all hit the -current (development) tree.

Great! I guess I should install -current now

ponce · 11-15-2010, 12:22 AM

thanks Robby for your huge work on this

grissiom · 11-15-2010, 02:25 AM

Quote:

Originally Posted by rworkman

Okay, as everyone should have noticed by now, this has all hit the -current (development) tree. You'll need to remove the talloc package before upgrading - rather than split talloc into a separate package, Pat elected to put the library in aaa_elflibs.

Thanks for the effort on this!

But, slackpkg won't upgrade aaa_elflibs automatically. And the slack-desc even suggest against upgrading it. So putting things there is good for fresh install but could be a bomb for -current trackers....

ponce · 11-15-2010, 03:35 AM

I think you can safely update aaa_elflibs today: it's not advised to update it later on, when it may overwrite updated libraries in the meantime.
Stuart Winter wrote something on the subject.

but I can understand you: a clean, fresh install is tasty

rworkman · 11-15-2010, 08:47 AM

Re aaa_elflibs:
http://www.linuxquestions.org/questi...1/#post3643890
http://www.linuxquestions.org/questi...ml#post3839404