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 runn
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 fixe
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 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 comp
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/u
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 32
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 x1
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 corre
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 corr
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 t
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... Key
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.
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 break
[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
14 matches
Mail list logo
