Bug#562052: Correctly identify touchpads

2010-01-10 Thread Michael Tokarev 
Dmitry Torokhov wrote:
 On Sun, Jan 10, 2010 at 02:01:08AM +0300, Michael Tokarev wrote:
 Dmitry Torokhov wrote:
 []
 This is exactly what happens, to me and to the original bug reporter --
 we both are running 32bit userspace and 64bit kernel.
 []
 Does the following patch fixes it for you guys?
 No, Dmitry, it does not.  It's buggy.

 With this patch applied, the bits are all completely wrong.

[]
 Doh, amazing what min/max mixup will do. The patch below should fix
 that.

With the fixup applied on top of previous patch, the whole thing
appears to work correctly.  2.6.32-amd64:

32bit grep:
/sys/devices/platform/i8042/serio4/input/input6/capabilities# grep . *
abs:1103
ev:b
ff:0
key:6420 0 7000f 0 0 0 0 0 0 0 0
led:0
msc:0
rel:0
snd:0
sw:0

64bit grep:
/sys/devices/platform/i8042/serio4/input/input6/capabilities# ~/grep . *
abs:1103
ev:b
ff:0
key:6420 7000f 0 0 0 0
led:0
msc:0
rel:0
snd:0
sw:0

A few questions still:

o I think the 'key' attribute used to be shorter previously, eliminating
  unnecessary trailing zeros, but it is not anymore.  Just curious.

o How about other systems such as sparc 32/64 or power 32/64?  I'm not
  sure the patch is endian-clean.

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2010-01-10 Thread Dmitry Torokhov 
On Sun, Jan 10, 2010 at 03:27:02PM +0300, Michael Tokarev wrote:
 Dmitry Torokhov wrote:
  On Sun, Jan 10, 2010 at 02:01:08AM +0300, Michael Tokarev wrote:
  Dmitry Torokhov wrote:
  []
  This is exactly what happens, to me and to the original bug reporter --
  we both are running 32bit userspace and 64bit kernel.
  []
  Does the following patch fixes it for you guys?
  No, Dmitry, it does not.  It's buggy.
 
  With this patch applied, the bits are all completely wrong.
 
 []
  Doh, amazing what min/max mixup will do. The patch below should fix
  that.
 
 With the fixup applied on top of previous patch, the whole thing
 appears to work correctly.  2.6.32-amd64:

Great! Thank you very much for testing.

 
 32bit grep:
 /sys/devices/platform/i8042/serio4/input/input6/capabilities# grep . *
 abs:1103
 ev:b
 ff:0
 key:6420 0 7000f 0 0 0 0 0 0 0 0
 led:0
 msc:0
 rel:0
 snd:0
 sw:0
 
 64bit grep:
 /sys/devices/platform/i8042/serio4/input/input6/capabilities# ~/grep . *
 abs:1103
 ev:b
 ff:0
 key:6420 7000f 0 0 0 0
 led:0
 msc:0
 rel:0
 snd:0
 sw:0
 
 A few questions still:
 
 o I think the 'key' attribute used to be shorter previously, eliminating
   unnecessary trailing zeros, but it is not anymore.  Just curious.

No, you can only eliminate leading zeroes, otherwise how would you know
which is the starting bit?

 
 o How about other systems such as sparc 32/64 or power 32/64?  I'm not
   sure the patch is endian-clean.

I believe it is endian clean because I am using shifts to get dwords out
of u64 instead of trying to address them directly (which would require
different handling on LE vs. BE).

Thanks.

-- 
Dmitry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2010-01-09 Thread Michael Tokarev 
Dmitry Torokhov wrote:
[]
 This is exactly what happens, to me and to the original bug reporter --
 we both are running 32bit userspace and 64bit kernel.
[]
 Does the following patch fixes it for you guys?

No, Dmitry, it does not.  It's buggy.

With this patch applied, the bits are all completely wrong.

# hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/key
  00 00 00 00 20 30 20 00  00 00 00 00 20 30 20 00  | 0 . 0 .|
0010  20 30 20 00 20 30 20 00  20 30 20 00 0a   | 0 . 0 . 0 ..|
001d
# hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/ev
  00 0a |..|
0002

The same's in /proc/bus/input/devices, obviously.

I'll try to take a look at the patch tomorrow.

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2010-01-09 Thread Dmitry Torokhov 
On Sun, Jan 10, 2010 at 02:01:08AM +0300, Michael Tokarev wrote:
 Dmitry Torokhov wrote:
 []
  This is exactly what happens, to me and to the original bug reporter --
  we both are running 32bit userspace and 64bit kernel.
 []
  Does the following patch fixes it for you guys?
 
 No, Dmitry, it does not.  It's buggy.
 
 With this patch applied, the bits are all completely wrong.
 
 # hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/key
   00 00 00 00 20 30 20 00  00 00 00 00 20 30 20 00  | 0 . 0 .|
 0010  20 30 20 00 20 30 20 00  20 30 20 00 0a   | 0 . 0 . 0 ..|
 001d
 # hexdump -C /sys/devices/platform/i8042/serio4/input/input6/capabilities/ev
   00 0a |..|
 0002
 
 The same's in /proc/bus/input/devices, obviously.
 
 I'll try to take a look at the patch tomorrow.
 
 Thanks!
 

Doh, amazing what min/max mixup will do. The patch below should fix
that.

-- 
Dmitry

input compat fixup.

Signed-off-by: Dmitry Torokhov d...@mail.ru
---

 drivers/input/input.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/drivers/input/input.c b/drivers/input/input.c
index 687ea63..94385b9 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -838,13 +838,13 @@ static int input_bits_to_string(char *buf, int buf_size,
int len = 0;
 
if (INPUT_COMPAT_TEST) {
-   u32 dword = (bits  0xUL)  32;
+   u32 dword = bits  32;
if (dword || !skip_empty)
len += snprintf(buf, buf_size, %x , dword);
 
-   dword = (bits  0xUL);
+   dword = bits  0xUL;
if (dword || !skip_empty || len)
-   len += snprintf(buf + len, min(buf_size - len, 0),
+   len += snprintf(buf + len, max(buf_size - len, 0),
%x, dword);
} else {
if (bits || !skip_empty)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-30 Thread Martin Pitt 
Michael Tokarev [2009-12-25  1:51 +0300]:
  Not really :( We print in groups of longs so it is either 32 or 64 bits
  worth of data per number.
 
 Ok, I stand corrected.  I verified the issue with 32bit kernel, and
 there, hald works as expected, listing `synaptics' as x11_driver
 and correct input.touchpad capability.

Just to have all the data, could you please find the input device
number (from lshal, as you did before), and send the output of

  cat /sys/class/input/inputX/capabilities/key

(replace X with the particular input device number) under a 32 and 64
bit system?

Also, do you get correct or wrong ID_INPUT_* flags for the synaptics
device in udevadm info --export-db|less? I expect it to be wrong as
well, since it's pretty much the same code.

udev/hal already use sizeof(long) to determine the length of a long
word length, and it doesn't seem to happen everywhere. (I am running a
64 bit kernel/userspace and get correct results).

I might have misunderstood you, but did you actually try to run a 64
bit kernel under 32 bit userspace? That would explain the bug, since
hal/udev were compiled with the assumption that sizeof(long) == 4,
while the kernel prints those in groups of 8 bytes.

So if we want to support mixed kernel/userspace word lenghts, we need
to change the logic to do a dynamic word size detection based on
uname().

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-30 Thread Michael Tokarev 
Martin Pitt wrote:
 Michael Tokarev [2009-12-25  1:51 +0300]:
 Not really :( We print in groups of longs so it is either 32 or 64 bits
 worth of data per number.
 Ok, I stand corrected.  I verified the issue with 32bit kernel, and
 there, hald works as expected, listing `synaptics' as x11_driver
 and correct input.touchpad capability.
 
 Just to have all the data, could you please find the input device
 number (from lshal, as you did before), and send the output of
 
   cat /sys/class/input/inputX/capabilities/key
 
 (replace X with the particular input device number) under a 32 and 64
 bit system?

It's shown in /proc/bus/input/devices too.  Sure I can, here we go:

32bit: 6420 0 7000f 0 0 0 0 0 0 0 0
64bit: 6420 7000f 0 0 0 0

 Also, do you get correct or wrong ID_INPUT_* flags for the synaptics
 device in udevadm info --export-db|less? I expect it to be wrong as
 well, since it's pretty much the same code.

in both cases userspace is 32bit, but kernel bitness is different:

32bit:
P: /devices/platform/i8042/serio4/input/input9
E: UDEV_LOG=3
E: DEVPATH=/devices/platform/i8042/serio4/input/input9
E: PRODUCT=11/2/7/12b1
E: NAME=SynPS/2 Synaptics TouchPad
E: PHYS=isa0060/serio4/input0
E: EV==b
E: KEY==6420 0 7000f 0 0 0 0 0 0 0 0
E: ABS==1103
E: 
MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw
E: SUBSYSTEM=input

64bit:
P: /devices/platform/i8042/serio4/input/input9
E: UDEV_LOG=3
E: DEVPATH=/devices/platform/i8042/serio4/input/input9
E: PRODUCT=11/2/7/12b1
E: NAME=SynPS/2 Synaptics TouchPad
E: PHYS=isa0060/serio4/input0
E: EV==b
E: KEY==6420 7000f 0 0 0 0
E: ABS==1103
E: 
MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw
E: SUBSYSTEM=input

Udev merely collects text attributes from sysfs, so it's expected
that all the attributes are the same as kernel says they are.

 udev/hal already use sizeof(long) to determine the length of a long
 word length, and it doesn't seem to happen everywhere. (I am running a
 64 bit kernel/userspace and get correct results).

It works correctly with 32bit userspace and 32bit kernel too.

 I might have misunderstood you, but did you actually try to run a 64
 bit kernel under 32 bit userspace? That would explain the bug, since
 hal/udev were compiled with the assumption that sizeof(long) == 4,
 while the kernel prints those in groups of 8 bytes.

This is exactly what happens, to me and to the original bug reporter --
we both are running 32bit userspace and 64bit kernel.

Note that the difference between ioctl and sysfs is exactly in this
kind of issues: to be independent of word size... ;)

 So if we want to support mixed kernel/userspace word lenghts, we need
 to change the logic to do a dynamic word size detection based on
 uname().

Not uname please.  There should be a better way :)

For example, see the number of words shown in key attribute:
for 32bits it's two times of 64bits...

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-30 Thread Dmitry Torokhov 
On Wed, Dec 30, 2009 at 02:01:09PM +0300, Michael Tokarev wrote:
 Martin Pitt wrote:
  Michael Tokarev [2009-12-25  1:51 +0300]:
  Not really :( We print in groups of longs so it is either 32 or 64 bits
  worth of data per number.
  Ok, I stand corrected.  I verified the issue with 32bit kernel, and
  there, hald works as expected, listing `synaptics' as x11_driver
  and correct input.touchpad capability.
  
  Just to have all the data, could you please find the input device
  number (from lshal, as you did before), and send the output of
  
cat /sys/class/input/inputX/capabilities/key
  
  (replace X with the particular input device number) under a 32 and 64
  bit system?
 
 It's shown in /proc/bus/input/devices too.  Sure I can, here we go:
 
 32bit: 6420 0 7000f 0 0 0 0 0 0 0 0
 64bit: 6420 7000f 0 0 0 0
 
  Also, do you get correct or wrong ID_INPUT_* flags for the synaptics
  device in udevadm info --export-db|less? I expect it to be wrong as
  well, since it's pretty much the same code.
 
 in both cases userspace is 32bit, but kernel bitness is different:
 
 32bit:
 P: /devices/platform/i8042/serio4/input/input9
 E: UDEV_LOG=3
 E: DEVPATH=/devices/platform/i8042/serio4/input/input9
 E: PRODUCT=11/2/7/12b1
 E: NAME=SynPS/2 Synaptics TouchPad
 E: PHYS=isa0060/serio4/input0
 E: EV==b
 E: KEY==6420 0 7000f 0 0 0 0 0 0 0 0
 E: ABS==1103
 E: 
 MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw
 E: SUBSYSTEM=input
 
 64bit:
 P: /devices/platform/i8042/serio4/input/input9
 E: UDEV_LOG=3
 E: DEVPATH=/devices/platform/i8042/serio4/input/input9
 E: PRODUCT=11/2/7/12b1
 E: NAME=SynPS/2 Synaptics TouchPad
 E: PHYS=isa0060/serio4/input0
 E: EV==b
 E: KEY==6420 7000f 0 0 0 0
 E: ABS==1103
 E: 
 MODALIAS=input:b0011v0002p0007e12B1-e0,1,3,k100,101,102,103,110,111,112,145,14A,14D,14E,ra0,1,18,1C,mlsfw
 E: SUBSYSTEM=input
 
 Udev merely collects text attributes from sysfs, so it's expected
 that all the attributes are the same as kernel says they are.
 
  udev/hal already use sizeof(long) to determine the length of a long
  word length, and it doesn't seem to happen everywhere. (I am running a
  64 bit kernel/userspace and get correct results).
 
 It works correctly with 32bit userspace and 32bit kernel too.
 
  I might have misunderstood you, but did you actually try to run a 64
  bit kernel under 32 bit userspace? That would explain the bug, since
  hal/udev were compiled with the assumption that sizeof(long) == 4,
  while the kernel prints those in groups of 8 bytes.
 
 This is exactly what happens, to me and to the original bug reporter --
 we both are running 32bit userspace and 64bit kernel.
 
 Note that the difference between ioctl and sysfs is exactly in this
 kind of issues: to be independent of word size... ;)
 
  So if we want to support mixed kernel/userspace word lenghts, we need
  to change the logic to do a dynamic word size detection based on
  uname().
 
 Not uname please.  There should be a better way :)
 
 For example, see the number of words shown in key attribute:
 for 32bits it's two times of 64bits...
 

I think we'll just have to make kernel output in 32 bits for compat
processes.

-- 
Dmitry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-30 Thread Martin Pitt 
Michael Tokarev [2009-12-30 14:01 +0300]:
 in both cases userspace is 32bit, but kernel bitness is different:

Ah, thanks.

 Udev merely collects text attributes from sysfs, 

No, it also stores properties set in udev rules. I was particularly
interested in the ID_INPUT_* properties set by
/lib/udev/rules.d/60-persistent-input.rules, but they are not in your
dump.

 This is exactly what happens, to me and to the original bug reporter --
 we both are running 32bit userspace and 64bit kernel.

OK, thanks. Then it's quite clear why this happens.

  So if we want to support mixed kernel/userspace word lenghts, we need
  to change the logic to do a dynamic word size detection based on
  uname().
 
 Not uname please.  There should be a better way :)

I don't like it either, since you have to compare with a lot of fixed
strings, for each supported architecture. Do you know a better way of
asking the kernel for its word size?

 For example, see the number of words shown in key attribute:
 for 32bits it's two times of 64bits...

Not really. The attribute has as many words as necessary for the
highest bit set. E. g. many input devices have a single 0 there.
Check cat /sys/class/input*/capabilities/key.

If the kernel would have an architecture independent representation of
those bits in the sys attribute, that would help a lot indeed. Right
now, I don't think we can sanely support mixed kernel/userspace
architectures.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-25 Thread Michael Tokarev 
Michael Tokarev wrote:
 Dmitry Torokhov wrote:
 On Thu, Dec 24, 2009 at 11:32:27PM +0300, Michael Tokarev wrote:

 B: KEY=6420 7000f 0 0 0 0
 B: ABS=1103
[]
 Not really :( We print in groups of longs so it is either 32 or 64 bits
 worth of data per number.
 
 Ok, I stand corrected.  I verified the issue with 32bit kernel, and
 there, hald works as expected, listing `synaptics' as x11_driver
 and correct input.touchpad capability.

So the question is how userspace can detect the right size.

The above example shows 6 groups of numbers.  With 32bit kernel that
turns into 12 groups.  Is that enough clue?

How about changing kernel interface to print whole number in one go?

And the bug appears to be in kernel really, but assigning it to hal
at this point makes sense.

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-24 Thread Michael Tokarev 
[commit 52e039f3b0a5749f706b97491087b9632d30512f in hal git tree,
http://cgit.freedesktop.org/hal/commit/?id=52e039f3b0a5749f706b97491087b9632d30512f]

That commit in hal (released as 0.5.14) - apparently -
causes some breakage.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562052
is one example (with my comments, Cc'd).

Basically, in some cases synaptics touchpad is not
recognized as touchpad by hal and hence wrong driver
gets loaded.

My example:

I: Bus=0011 Vendor=0002 Product=0007 Version=12b1
N: Name=SynPS/2 Synaptics TouchPad
B: EV=b
B: KEY=6420 7000f 0 0 0 0
B: ABS=1103

(it's an Acer Aspire 9300 notebook, the touchpad has
3 buttons, middle of which is like the main ok
button on a typical cell phone -- one can press it
to center and to any of 4 other directions).

With this hunk:

@@ -1184,9 +1182,4 @@ input_test_abs (HalDevice *d, const char
}
}
-
-   if (test_bit (ABS_PRESSURE, bitmask_abs)) {
-   hal_device_add_capability (d, input.touchpad);
-   goto out;
-   }
}
 out:

(ie, without the ABS_PRESSURE test) the device is not recognized
as a touchpad.  Adding this test back restores things to normal.
The other change in that patch, BTN_TOUCH = BTN_TOOL_FINGER,
has no effect.

The kernel is 2.6.32 currently.

What's wrong? ;)

Thanks!

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-24 Thread Dmitry Torokhov 
On Thu, Dec 24, 2009 at 08:59:47PM +0300, Michael Tokarev wrote:
 [commit 52e039f3b0a5749f706b97491087b9632d30512f in hal git tree,
 http://cgit.freedesktop.org/hal/commit/?id=52e039f3b0a5749f706b97491087b9632d30512f]
 
 That commit in hal (released as 0.5.14) - apparently -
 causes some breakage.
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562052
 is one example (with my comments, Cc'd).
 
 Basically, in some cases synaptics touchpad is not
 recognized as touchpad by hal and hence wrong driver
 gets loaded.
 
 My example:
 
 I: Bus=0011 Vendor=0002 Product=0007 Version=12b1
 N: Name=SynPS/2 Synaptics TouchPad
 B: EV=b
 B: KEY=6420 7000f 0 0 0 0
 B: ABS=1103
 
 (it's an Acer Aspire 9300 notebook, the touchpad has
 3 buttons, middle of which is like the main ok
 button on a typical cell phone -- one can press it
 to center and to any of 4 other directions).
 
 With this hunk:
 
 @@ -1184,9 +1182,4 @@ input_test_abs (HalDevice *d, const char
 }
 }
 -
 -   if (test_bit (ABS_PRESSURE, bitmask_abs)) {
 -   hal_device_add_capability (d, input.touchpad);
 -   goto out;
 -   }
 }
  out:
 
 (ie, without the ABS_PRESSURE test) the device is not recognized
 as a touchpad.  Adding this test back restores things to normal.
 The other change in that patch, BTN_TOUCH = BTN_TOOL_FINGER,
 has no effect.
 
 The kernel is 2.6.32 currently.
 
 What's wrong? ;)


Not sure, seems to be working here... Keying on ABS_PRESSURE is
definitely not correct as some touchpads to not report it and many
touchscreens do. Is this on 32 or 64 bit kernels? What about userspace?

-- 
Dmitry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-24 Thread Michael Tokarev 
Dmitry Torokhov wrote:
[]
 B: KEY=6420 7000f 0 0 0 0
 B: ABS=1103

[]
 -   if (test_bit (ABS_PRESSURE, bitmask_abs)) {
[]
 What's wrong? ;)
 
 Not sure, seems to be working here... Keying on ABS_PRESSURE is

It apparently works on some laptops here and fails on others.

 definitely not correct as some touchpads to not report it and many
 touchscreens do. Is this on 32 or 64 bit kernels? What about userspace?

32bit userspace, either 32 or 64bit kernel.  But since the string
as read from sysfs does not depend on kernel bitness, both should
be irrelevant... I hope.

/mjt



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-24 Thread Dmitry Torokhov 
On Thu, Dec 24, 2009 at 11:32:27PM +0300, Michael Tokarev wrote:
 Dmitry Torokhov wrote:
 []
  B: KEY=6420 7000f 0 0 0 0
  B: ABS=1103
 
 []
  -   if (test_bit (ABS_PRESSURE, bitmask_abs)) {
 []
  What's wrong? ;)
  
  Not sure, seems to be working here... Keying on ABS_PRESSURE is
 
 It apparently works on some laptops here and fails on others.
 
  definitely not correct as some touchpads to not report it and many
  touchscreens do. Is this on 32 or 64 bit kernels? What about userspace?
 
 32bit userspace, either 32 or 64bit kernel.  But since the string
 as read from sysfs does not depend on kernel bitness, both should
 be irrelevant... I hope.
 

Not really :( We print in groups of longs so it is either 32 or 64 bits
worth of data per number.

-- 
Dmitry



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562052: Correctly identify touchpads

2009-12-24 Thread Michael Tokarev 
Dmitry Torokhov wrote:
 On Thu, Dec 24, 2009 at 11:32:27PM +0300, Michael Tokarev wrote:
 Dmitry Torokhov wrote:
 []
 B: KEY=6420 7000f 0 0 0 0
 B: ABS=1103

 []
 -   if (test_bit (ABS_PRESSURE, bitmask_abs)) {
 []
 What's wrong? ;)
 Not sure, seems to be working here... Keying on ABS_PRESSURE is
 It apparently works on some laptops here and fails on others.

 definitely not correct as some touchpads to not report it and many
 touchscreens do. Is this on 32 or 64 bit kernels? What about userspace?
 32bit userspace, either 32 or 64bit kernel.  But since the string
 as read from sysfs does not depend on kernel bitness, both should
 be irrelevant... I hope.
 
 Not really :( We print in groups of longs so it is either 32 or 64 bits
 worth of data per number.

Ok, I stand corrected.  I verified the issue with 32bit kernel, and
there, hald works as expected, listing `synaptics' as x11_driver
and correct input.touchpad capability.

Oh well.

/mjt





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org