LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 11-06-2010, 08:29 AM   #181
grissiom
Member
 
Registered: Apr 2008
Location: China, Beijing
Distribution: Slackware
Posts: 423

Rep: Reputation: 45

@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!
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 11-06-2010, 07:44 PM   #182
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,656

Rep: Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233
Quote:
Originally Posted by rworkman View Post
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.
Attached Files
File Type: log Xorg.0.log (26.6 KB, 0 views)
File Type: txt evdev.c.txt (78.2 KB, 0 views)
File Type: txt xf86Xinput.c.txt (39.5 KB, 0 views)

Last edited by Didier Spaier; 11-06-2010 at 07:45 PM.
 
Old 11-06-2010, 09:15 PM   #183
grissiom
Member
 
Registered: Apr 2008
Location: China, Beijing
Distribution: Slackware
Posts: 423

Rep: Reputation: 45
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.
 
Old 11-06-2010, 10:06 PM   #184
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,944

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Didier Spaier View Post
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.
 
Old 11-07-2010, 11:44 AM   #185
zsd
Member
 
Registered: Dec 2005
Location: Nova Scotia
Distribution: Slackware
Posts: 69

Rep: Reputation: 24
1.9.2 and Fujitsu T900

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.
 
Old 11-07-2010, 01:04 PM   #186
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,944

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by zsd View Post
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
 
Old 11-09-2010, 10:55 AM   #187
zsd
Member
 
Registered: Dec 2005
Location: Nova Scotia
Distribution: Slackware
Posts: 69

Rep: Reputation: 24
Quote:
Originally Posted by rworkman View Post
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 :-(

Last edited by zsd; 11-10-2010 at 09:07 PM.
 
Old 11-11-2010, 02:04 PM   #188
imitheos
Member
 
Registered: May 2005
Location: Greece
Posts: 374

Rep: Reputation: 55
Quote:
Originally Posted by Didier Spaier View Post
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
 
Old 11-13-2010, 06:22 PM   #189
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
While the out of tree packages arent updated anymore theres an X11R7.6 RC 1 announcement
http://lists.freedesktop.org/archive...er/051792.html
 
Old 11-15-2010, 12:55 AM   #190
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,944

Original Poster
Rep: Reputation: Disabled
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.
 
3 members found this post helpful.
Old 11-15-2010, 01:20 AM   #191
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,656

Rep: Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233Reputation: 1233
Quote:
Originally Posted by rworkman View Post
Okay, as everyone should have noticed by now, this has all hit the -current (development) tree.
Great! I guess I should install -current now
 
Old 11-15-2010, 01:22 AM   #192
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
thanks Robby for your huge work on this
 
Old 11-15-2010, 03:25 AM   #193
grissiom
Member
 
Registered: Apr 2008
Location: China, Beijing
Distribution: Slackware
Posts: 423

Rep: Reputation: 45
Quote:
Originally Posted by rworkman View Post
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....
 
Old 11-15-2010, 04:35 AM   #194
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
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

Last edited by ponce; 11-15-2010 at 04:58 AM.
 
Old 11-15-2010, 09:47 AM   #195
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,944

Original Poster
Rep: Reputation: Disabled
Re aaa_elflibs:
http://www.linuxquestions.org/questi...1/#post3643890
http://www.linuxquestions.org/questi...ml#post3839404
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
No updates in Testing? war1025 Debian 2 07-08-2009 01:16 PM
[Call for testing] ibus SlackBuild grissiom Slackware 6 05-19-2009 11:39 AM
Testing is inadequate for new updates Lsatenstein Fedora 3 12-24-2006 12:19 PM
security updates for testing branch uselpa Debian 4 09-15-2006 02:09 AM
Anyone tried 2.6.11 in updates/testing ? snecklifter Fedora 7 04-08-2005 10:13 AM


All times are GMT -5. The time now is 04:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration