Re: Strange issue with hal and Xorg [SOLVED-Workaround]

2009-06-16 Thread Matt Hayes
Matt Hayes wrote:
 Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and
 ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy.
 
 Well, after the latest updates to Slackware and Xorg, what I'm seeing
 now is the side buttons on my Microsoft Intellimouse Explorer 3 are
 mapping the buttons (side buttons) as 8 9 instead of 6 7.
 
 However, making a change in xorg.conf to facilitate the change in
 mapping, things DO work fine in X, but not other applications such as
 Enemy Territory.
 
 Below is my xinput list:
 
 Virtual core pointer  id=0[XPointer]
 Num_buttons is 32
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
 Min_value is -1
 Max_value is -1
 Resolution is 0
 Axis 1 :
 Min_value is -1
 Max_value is -1
 Resolution is 0
 Virtual core keyboard id=1[XKeyboard]
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
 Macintosh mouse button emulation  id=2[XExtensionPointer]
 Type is MOUSE
 Num_buttons is 32
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
 Min_value is -1
 Max_value is -1
 Resolution is 1
 Axis 1 :
 Min_value is -1
 Max_value is -1
 Resolution is 1
 AT Translated Set 2 keyboard  id=3[XExtensionKeyboard]
 Type is KEYBOARD
 Num_keys is 248
 Min_keycode is 8
 Max_keycode is 255
 Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)id=4
 [XExtensionPointer]
 Type is MOUSE
 Num_buttons is 32
 Num_axes is 2
 Mode is Relative
 Motion_buffer is 256
 Axis 0 :
 Min_value is -1
 Max_value is -1
 Resolution is 1
 Axis 1 :
 Min_value is -1
 Max_value is -1
 Resolution is 1
 
 
 
 
 
 Now, what I don't understand is why hal is detecting the mouse as
 Num_buttons 32... I even created a hal policy to map the buttons how I
 normally would in xorg.conf and this had no effect.
 
 I'm at a loss.
 
 -Matt
 

Ok, well I finally got this figured it out.  The issue was evdev, of
course, some of the suggestions everyone made got me digging through
some research.

I added:

Section ServerFlags
Option AutoAddDevices False
Option AllowEmptyInput False
EndSection

To my xorg.conf, restarted X, and what do you know.. .mouse buttons map
properly and Enemy Territory again picks it up.

Basically telling hal to go away :)

I know its more of a band-aid, but it works


Thanks everyone for the help,

Matt
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg [SOLVED-Workaround]

2009-06-16 Thread Justin Mattock
On Tue, Jun 16, 2009 at 9:36 AM, Matt Hayesdomin...@slackadelic.com wrote:
 Matt Hayes wrote:
 Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and
 ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy.

 Well, after the latest updates to Slackware and Xorg, what I'm seeing
 now is the side buttons on my Microsoft Intellimouse Explorer 3 are
 mapping the buttons (side buttons) as 8 9 instead of 6 7.

 However, making a change in xorg.conf to facilitate the change in
 mapping, things DO work fine in X, but not other applications such as
 Enemy Territory.

 Below is my xinput list:

 Virtual core pointer  id=0    [XPointer]
         Num_buttons is 32
         Num_axes is 2
         Mode is Relative
         Motion_buffer is 256
         Axis 0 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 0
         Axis 1 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 0
 Virtual core keyboard id=1    [XKeyboard]
         Num_keys is 248
         Min_keycode is 8
         Max_keycode is 255
 Macintosh mouse button emulation      id=2    [XExtensionPointer]
         Type is MOUSE
         Num_buttons is 32
         Num_axes is 2
         Mode is Relative
         Motion_buffer is 256
         Axis 0 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 1
         Axis 1 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 1
 AT Translated Set 2 keyboard  id=3    [XExtensionKeyboard]
         Type is KEYBOARD
         Num_keys is 248
         Min_keycode is 8
         Max_keycode is 255
 Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)        id=4
 [XExtensionPointer]
         Type is MOUSE
         Num_buttons is 32
         Num_axes is 2
         Mode is Relative
         Motion_buffer is 256
         Axis 0 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 1
         Axis 1 :
                 Min_value is -1
                 Max_value is -1
                 Resolution is 1





 Now, what I don't understand is why hal is detecting the mouse as
 Num_buttons 32... I even created a hal policy to map the buttons how I
 normally would in xorg.conf and this had no effect.

 I'm at a loss.

 -Matt


 Ok, well I finally got this figured it out.  The issue was evdev, of
 course, some of the suggestions everyone made got me digging through
 some research.

 I added:

 Section ServerFlags
 Option AutoAddDevices False
 Option AllowEmptyInput False
 EndSection

 To my xorg.conf, restarted X, and what do you know.. .mouse buttons map
 properly and Enemy Territory again picks it up.

 Basically telling hal to go away :)

 I know its more of a band-aid, but it works


 Thanks everyone for the help,

 Matt
 ___
 xorg mailing list
 xorg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xorg


Cool, glad it works for you..


-- 
Justin P. Mattock
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Peter Hutterer
On Fri, Jun 12, 2009 at 12:20:16AM -0400, Matt Hayes wrote:
 Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and
 ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy.
 
 Well, after the latest updates to Slackware and Xorg, what I'm seeing
 now is the side buttons on my Microsoft Intellimouse Explorer 3 are
 mapping the buttons (side buttons) as 8 9 instead of 6 7.
 
 However, making a change in xorg.conf to facilitate the change in
 mapping, things DO work fine in X, but not other applications such as
 Enemy Territory.

if HAL takes effect, xorg.conf sections are generally ignored these days. So
chances are it's not even picking up what you have configured.

the other chance is of course that your DE is overwriting it on login.
 
 Now, what I don't understand is why hal is detecting the mouse as
 Num_buttons 32... I even created a hal policy to map the buttons how I
 normally would in xorg.conf and this had no effect.

HAL is not detecting anything. Think of hal being the equivalent to the
Option Device /dev/input/event1 line. That's really all it does.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Matt Hayes
Hrm.. so where the heck is the 32 buttons coming from?  That's very
odd and causes mapping of buttons to be a pita.

-Matt

Peter Hutterer wrote:
 On Fri, Jun 12, 2009 at 12:20:16AM -0400, Matt Hayes wrote:
 Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and
 ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy.

 Well, after the latest updates to Slackware and Xorg, what I'm seeing
 now is the side buttons on my Microsoft Intellimouse Explorer 3 are
 mapping the buttons (side buttons) as 8 9 instead of 6 7.

 However, making a change in xorg.conf to facilitate the change in
 mapping, things DO work fine in X, but not other applications such as
 Enemy Territory.
 
 if HAL takes effect, xorg.conf sections are generally ignored these days. So
 chances are it's not even picking up what you have configured.
 
 the other chance is of course that your DE is overwriting it on login.
  
 Now, what I don't understand is why hal is detecting the mouse as
 Num_buttons 32... I even created a hal policy to map the buttons how I
 normally would in xorg.conf and this had no effect.
 
 HAL is not detecting anything. Think of hal being the equivalent to the
 Option Device /dev/input/event1 line. That's really all it does.
 
 Cheers,
   Peter


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Dan Nicholson
On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.

The evdev driver. Perhaps you were using the mouse driver in xorg.conf?

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Strange issue with hal and Xorg

2009-06-12 Thread Matt Hayes
Dan Nicholson wrote:
 On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.
 
 The evdev driver. Perhaps you were using the mouse driver in xorg.conf?
 

That is possible.  I will have to look at changing the mouse driver in a
hal policy or Xorg.conf and see what that reveals.

-Matt

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread walt
Matt Hayes wrote:
 Dan Nicholson wrote:
 On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com  wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.
 The evdev driver. Perhaps you were using the mouse driver in xorg.conf?


 That is possible.  I will have to look at changing the mouse driver in a
 hal policy or Xorg.conf and see what that reveals.

I recently switched to using evdev and when I removed the InputDevice sections
from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly
named 10-x11-logitech.fdi) containing this:

?xml version=1.0 encoding=ISO-8859-1?
deviceinfo version=0.2
   device
 match key=info.product contains=ImExPS/2
   merge key=input.x11_options.EmulateWheel type=stringtrue/merge
   merge key=input.x11_options.EmulateWheelButton type=string8/merge
 /match
   /device
/deviceinfo

I constructed that file by looking at mouse-oriented parts of the output of
'lshal' and just stuck the options in where it looked reasonable.

It worked, and I'm still amazed.

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Matt Hayes
walt wrote:
 Matt Hayes wrote:
 Dan Nicholson wrote:
 On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com  
 wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.
 The evdev driver. Perhaps you were using the mouse driver in xorg.conf?

 That is possible.  I will have to look at changing the mouse driver in a
 hal policy or Xorg.conf and see what that reveals.
 
 I recently switched to using evdev and when I removed the InputDevice sections
 from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I 
 cleverly
 named 10-x11-logitech.fdi) containing this:
 
 ?xml version=1.0 encoding=ISO-8859-1?
 deviceinfo version=0.2
device
  match key=info.product contains=ImExPS/2
merge key=input.x11_options.EmulateWheel type=stringtrue/merge
merge key=input.x11_options.EmulateWheelButton 
 type=string8/merge
  /match
/device
 /deviceinfo
 
 I constructed that file by looking at mouse-oriented parts of the output of
 'lshal' and just stuck the options in where it looked reasonable.
 
 It worked, and I'm still amazed.

Well, I will give that a shot.  I need to learn how this hal stuff works
anyway :)

-Matt

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Matt Hayes
Justin Mattock wrote:
 On Fri, Jun 12, 2009 at 11:06 AM, Matt Hayesdomin...@slackadelic.com wrote:
 walt wrote:
 Matt Hayes wrote:
 Dan Nicholson wrote:
 On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com  
 wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.
 The evdev driver. Perhaps you were using the mouse driver in xorg.conf?

 That is possible.  I will have to look at changing the mouse driver in a
 hal policy or Xorg.conf and see what that reveals.
 I recently switched to using evdev and when I removed the InputDevice 
 sections
 from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I 
 cleverly
 named 10-x11-logitech.fdi) containing this:

 ?xml version=1.0 encoding=ISO-8859-1?
 deviceinfo version=0.2
device
  match key=info.product contains=ImExPS/2
merge key=input.x11_options.EmulateWheel 
 type=stringtrue/merge
merge key=input.x11_options.EmulateWheelButton 
 type=string8/merge
  /match
/device
 /deviceinfo

 I constructed that file by looking at mouse-oriented parts of the output of
 'lshal' and just stuck the options in where it looked reasonable.

 It worked, and I'm still amazed.
 Well, I will give that a shot.  I need to learn how this hal stuff works
 anyway :)

 -Matt

 
 Don't want to confuse you, but hal
 is being fazed out.
 udev-142 is now responsible for handling
 volumeid etc...

Yeah.. now I'm confused

-Matt

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread Justin Mattock
On Fri, Jun 12, 2009 at 11:06 AM, Matt Hayesdomin...@slackadelic.com wrote:
 walt wrote:
 Matt Hayes wrote:
 Dan Nicholson wrote:
 On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com  
 wrote:
 Hrm.. so where the heck is the 32 buttons coming from?  That's very
 odd and causes mapping of buttons to be a pita.
 The evdev driver. Perhaps you were using the mouse driver in xorg.conf?

 That is possible.  I will have to look at changing the mouse driver in a
 hal policy or Xorg.conf and see what that reveals.

 I recently switched to using evdev and when I removed the InputDevice 
 sections
 from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I 
 cleverly
 named 10-x11-logitech.fdi) containing this:

 ?xml version=1.0 encoding=ISO-8859-1?
 deviceinfo version=0.2
    device
      match key=info.product contains=ImExPS/2
        merge key=input.x11_options.EmulateWheel type=stringtrue/merge
        merge key=input.x11_options.EmulateWheelButton 
 type=string8/merge
      /match
    /device
 /deviceinfo

 I constructed that file by looking at mouse-oriented parts of the output of
 'lshal' and just stuck the options in where it looked reasonable.

 It worked, and I'm still amazed.

 Well, I will give that a shot.  I need to learn how this hal stuff works
 anyway :)

 -Matt

 ___
 xorg mailing list
 xorg@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/xorg


Don't want to confuse you, but hal
is being fazed out.
udev-142 is now responsible for handling
volumeid etc...


-- 
Justin P. Mattock
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: Strange issue with hal and Xorg

2009-06-12 Thread walt
Justin Mattock wrote:

 Don't want to confuse you, but hal
 is being fazed out.
 udev-142 is now responsible for handling
 volumeid etc...

Auuuggh! Just when I'm beginning to understand hal (but not very well.)

You've confused me too.  How does volumeid relate to a mouse problem?
And which docs should I start reading before this actually happens?

And have a nice weekend :o)

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Strange issue with hal and Xorg

2009-06-11 Thread Matt Hayes
Normally, xorg.conf I could map my buttons using ZAxisMapping 4 5 and
ButtonMapping 1 2 3 6 7 and Buttons 7 and things were dandy.

Well, after the latest updates to Slackware and Xorg, what I'm seeing
now is the side buttons on my Microsoft Intellimouse Explorer 3 are
mapping the buttons (side buttons) as 8 9 instead of 6 7.

However, making a change in xorg.conf to facilitate the change in
mapping, things DO work fine in X, but not other applications such as
Enemy Territory.

Below is my xinput list:

Virtual core pointer  id=0[XPointer]
Num_buttons is 32
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is -1
Max_value is -1
Resolution is 0
Axis 1 :
Min_value is -1
Max_value is -1
Resolution is 0
Virtual core keyboard id=1[XKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Macintosh mouse button emulation  id=2[XExtensionPointer]
Type is MOUSE
Num_buttons is 32
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is -1
Max_value is -1
Resolution is 1
Axis 1 :
Min_value is -1
Max_value is -1
Resolution is 1
AT Translated Set 2 keyboard  id=3[XExtensionKeyboard]
Type is KEYBOARD
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)id=4
[XExtensionPointer]
Type is MOUSE
Num_buttons is 32
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is -1
Max_value is -1
Resolution is 1
Axis 1 :
Min_value is -1
Max_value is -1
Resolution is 1





Now, what I don't understand is why hal is detecting the mouse as
Num_buttons 32... I even created a hal policy to map the buttons how I
normally would in xorg.conf and this had no effect.

I'm at a loss.

-Matt
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg