I've been noticing a few quirks on the last few SVN snapshots, mostly regarding mouse events. I am using a Logitech Click! Mouse, which is a wireless unit that's connected via the PS/2 port on my motherboard.
The biggest bug so far has to do with the fact that gizmod will "eat" some context menus. For example right-clicking on Firefox windows will sometimes yield nothing. Other times it will show the context menu itself, but any mouse events will go "through" the menu, as if it weren't there at all. Another example of this is when I can click on some menu items, but other types (such as submenus or items that have radiobuttons or checkboxes) are unclickable. Using the keyboard to navigate and select these items works great though.
One more quirk that I wanted to add was that when using 'gizmod -g', sometimes I will see the key/mouse codes themselves instead of the constant names (i.e. KEY_BACK or BTN_MIDDLE), which makes coding a bit more difficult.
The last thing that I'd like to add is that the extra button in my Logitech Click! mouse will only work half of the time. gizmod -g will not even track it sometimes.
Other than these small issues, Gizmod is doing great on my machine. Please let me know if there's any further info that may be of help to you to resolve these issues ASAP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to admit I'm a bit perplexed. It shouldn't be possible for gizmod to eat events (unless exclusiveMode is turned on for that device). What happens inside the Linux kernel is the events get passed through the event subsystem, and (unless exclusive mode is turned on) there's no way that one observer can affect the event that gets passed on to other event observers.
Also, if gizmod -g isn't seeing an event, you can be pretty much guaranteed that the events aren't actually being generated. Do other applications receive the extra button events? You can verify if Linux is receiving the event at all by catting the appropriate device node (ie /dev/event0 or whatever it may be) and clicking the button. You'll see some garbage appear, but if it's working properly you should see garbage every time you click the button. (This is the garbage that gizmod translates into the events you see in gizmod -g).
Just out of curiosity, is the battery fully charged on your wireless mouse? :). I had a wireless mouse for a while and it would drop events sometimes when the battery was low.
But if that ain't it... could you try the catting the device node trick I mentioned above and let me know the results? Once that's done we'll just have to go from there.
As for the code appearing instead of the name in gizmod -g, is it happening randomly or always for specific events? And if so could you give me an example of the output?
Thanks again, I really appreciate any and all bug reports.
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After a few more days of testing different configurations, I am almost sure that Gizmod wasn't to blame when it came to mouse events being eaten. It seems that the Screenlets plugin in Beryl 0.3.0 might be the actual culprit. I will continue testing and report back.
As far as the other event stuff not being printed out, I'm out of guesses. Some key constants do get printed out, while others don't. I don't know if recompiling should fix this, but I will try this later tonight anyway. What I can be almost sure of is that my mouse's extra button not working is somehow tied to the aforementioned bug. Meaning, as soon as the events stopped being printed in gizmod -g, my mouse button stopped working as well.
Hope this helps!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll be curious to know what happens with the missing events (I too am a Beryl user). As for the key constants, could you provide a sample of the output where some of these key constants aren't being printed?
Thanks,
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The weird thing is that some other extra buttons will work just fine. For example, this happens when I press/release the "home" media button on my keyboard (to the left of my Tab key):
On a side note, I am also starting to believe that Murrine is the guilty party with all the weird menu stuff. I haven't had this happen again since I reconfigured it. I'm thinking I blamed gizmod too soon with this!
I've also just replaced my mouse's batteries, but I'm still not registering any events with the extra button on my mouse. It used to fire the "KEY_TASK" event constant before, but now... nothing.
Let me know if you need me to run some extra tests.
Cheers!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've actually run into this with a few other "fancy" logitech keyboards. Seems like the keyboard driver itself is to blame. If you press a button and an event isn't generated, the kernel module itself needs to be updated to support that button.
Also gizmod is designed not to output keycode strings for EV_MSC events (only EV_KEY) because most of the time (ie with normal devices :)), EV_MSC is reserved for events that aren't key presses and thus don't have a string value associated with them. In fact it would be impossible to come up with some string based on the MSC codes that would work for more than one device because devices have free reign over what they do with the MSC codes, whereas all devices must adhere to a standard when pushing out EV_KEY events.
So basically until the driver gets "fixed" I don't think there's anything that can be done, aside from just detecting the codes as they are, and going from there.
As for the extra button on the mouse... that's weird. Have you upgraded the kernel in the interim?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another thing that I forgot to mention is the fact that the KEY_WWW opens 2 things when pressed/released: Both a nautilus instance of my home folder, and a new Firefox tab with the same contents. This is the line that gets executed inside of my custom keyboard script:
Oh right... probably because the event is being fired once when the button is pushed and once when it is released :). Try: elif Event.Code == GizmoKey.KEY_WWW and Event.Value == 1:
or Event.Value == 0 depending on taste (1 means on key press, 0 means on key release, 2 means on key repeat).
Also it may be a good idea to do something like (where ____ == white space):
if Event.Value == 1 or Event.Value == 2:
____if ...
____elif Event.Code == GizmoKey.KEY_WWW:
________subprocess.Popen(["nautilus"])
________return True
See what I mean? The idea is to avoid having every key check Event.Value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I have finally nailed the problem with the context menus not being shown: It's definitely a Beryl/Compiz issue. It's even posted on their bugzilla database. Sorry for thinking it was Gizmod! lol
BTW, I switched to the new Compiz Fusion version and it rocks. Much better than Beryl IMO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Tim,
I've been noticing a few quirks on the last few SVN snapshots, mostly regarding mouse events. I am using a Logitech Click! Mouse, which is a wireless unit that's connected via the PS/2 port on my motherboard.
The biggest bug so far has to do with the fact that gizmod will "eat" some context menus. For example right-clicking on Firefox windows will sometimes yield nothing. Other times it will show the context menu itself, but any mouse events will go "through" the menu, as if it weren't there at all. Another example of this is when I can click on some menu items, but other types (such as submenus or items that have radiobuttons or checkboxes) are unclickable. Using the keyboard to navigate and select these items works great though.
One more quirk that I wanted to add was that when using 'gizmod -g', sometimes I will see the key/mouse codes themselves instead of the constant names (i.e. KEY_BACK or BTN_MIDDLE), which makes coding a bit more difficult.
The last thing that I'd like to add is that the extra button in my Logitech Click! mouse will only work half of the time. gizmod -g will not even track it sometimes.
Other than these small issues, Gizmod is doing great on my machine. Please let me know if there's any further info that may be of help to you to resolve these issues ASAP.
Hmm... well thanks for reporting the issues!
I have to admit I'm a bit perplexed. It shouldn't be possible for gizmod to eat events (unless exclusiveMode is turned on for that device). What happens inside the Linux kernel is the events get passed through the event subsystem, and (unless exclusive mode is turned on) there's no way that one observer can affect the event that gets passed on to other event observers.
Also, if gizmod -g isn't seeing an event, you can be pretty much guaranteed that the events aren't actually being generated. Do other applications receive the extra button events? You can verify if Linux is receiving the event at all by catting the appropriate device node (ie /dev/event0 or whatever it may be) and clicking the button. You'll see some garbage appear, but if it's working properly you should see garbage every time you click the button. (This is the garbage that gizmod translates into the events you see in gizmod -g).
Just out of curiosity, is the battery fully charged on your wireless mouse? :). I had a wireless mouse for a while and it would drop events sometimes when the battery was low.
But if that ain't it... could you try the catting the device node trick I mentioned above and let me know the results? Once that's done we'll just have to go from there.
As for the code appearing instead of the name in gizmod -g, is it happening randomly or always for specific events? And if so could you give me an example of the output?
Thanks again, I really appreciate any and all bug reports.
Tim.
After a few more days of testing different configurations, I am almost sure that Gizmod wasn't to blame when it came to mouse events being eaten. It seems that the Screenlets plugin in Beryl 0.3.0 might be the actual culprit. I will continue testing and report back.
As far as the other event stuff not being printed out, I'm out of guesses. Some key constants do get printed out, while others don't. I don't know if recompiling should fix this, but I will try this later tonight anyway. What I can be almost sure of is that my mouse's extra button not working is somehow tied to the aforementioned bug. Meaning, as soon as the events stopped being printed in gizmod -g, my mouse button stopped working as well.
Hope this helps!
Thanks for the update!
I'll be curious to know what happens with the missing events (I too am a Beryl user). As for the key constants, could you provide a sample of the output where some of these key constants aren't being printed?
Thanks,
Tim.
This was the exact output when I pressed the "music" button on my Logitech LX500 Keyboard (2nd button from the top left of the keyboard itself):
> onEvent: Standard -- /dev/input/event1 | [EV_MSC] c: 0x4 Val: 0x93
> onEvent: Standard -- /dev/input/event1 | [EV_MSC] c: 0x4 Val: 0x93
(one for press, one for release)
The weird thing is that some other extra buttons will work just fine. For example, this happens when I press/release the "home" media button on my keyboard (to the left of my Tab key):
> onEvent: Standard -- /dev/input/event1 | [EV_MSC] c: 0x4 Val: 0xb2
> onEvent: Standard -- /dev/input/event1 | [EV_KEY] <KEY_WWW> c: 0x96 v: 0x1
On a side note, I am also starting to believe that Murrine is the guilty party with all the weird menu stuff. I haven't had this happen again since I reconfigured it. I'm thinking I blamed gizmod too soon with this!
I've also just replaced my mouse's batteries, but I'm still not registering any events with the extra button on my mouse. It used to fire the "KEY_TASK" event constant before, but now... nothing.
Let me know if you need me to run some extra tests.
Cheers!
Hmmm interesting.
I've actually run into this with a few other "fancy" logitech keyboards. Seems like the keyboard driver itself is to blame. If you press a button and an event isn't generated, the kernel module itself needs to be updated to support that button.
Also gizmod is designed not to output keycode strings for EV_MSC events (only EV_KEY) because most of the time (ie with normal devices :)), EV_MSC is reserved for events that aren't key presses and thus don't have a string value associated with them. In fact it would be impossible to come up with some string based on the MSC codes that would work for more than one device because devices have free reign over what they do with the MSC codes, whereas all devices must adhere to a standard when pushing out EV_KEY events.
So basically until the driver gets "fixed" I don't think there's anything that can be done, aside from just detecting the codes as they are, and going from there.
As for the extra button on the mouse... that's weird. Have you upgraded the kernel in the interim?
Another thing that I forgot to mention is the fact that the KEY_WWW opens 2 things when pressed/released: Both a nautilus instance of my home folder, and a new Firefox tab with the same contents. This is the line that gets executed inside of my custom keyboard script:
---------------
elif Event.Code == GizmoKey.KEY_WWW:
subprocess.Popen(["nautilus"])
return True
---------------
Any ideas why this happens? TIA
Oh right... probably because the event is being fired once when the button is pushed and once when it is released :). Try: elif Event.Code == GizmoKey.KEY_WWW and Event.Value == 1:
or Event.Value == 0 depending on taste (1 means on key press, 0 means on key release, 2 means on key repeat).
Also it may be a good idea to do something like (where ____ == white space):
if Event.Value == 1 or Event.Value == 2:
____if ...
____elif Event.Code == GizmoKey.KEY_WWW:
________subprocess.Popen(["nautilus"])
________return True
See what I mean? The idea is to avoid having every key check Event.Value.
OK, I have finally nailed the problem with the context menus not being shown: It's definitely a Beryl/Compiz issue. It's even posted on their bugzilla database. Sorry for thinking it was Gizmod! lol
BTW, I switched to the new Compiz Fusion version and it rocks. Much better than Beryl IMO.
Good to know, and thanks the post is appreciated!
Also I just recently upgraded from Beryl to Compiz Fusion, and I have to agree... totally rocks!