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?
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
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
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
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
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
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,
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
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
[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
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.
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
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
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
14 matches
Mail list logo
