Hi,
Seems that I am running in "pothole detection mode" on my makesd-created stretch system, pressing the nubs does not cause a mouse button reaction. After some research I found out that the buttons seem to be part of the pyra-game-buttons device and that is treated as keyboard by x11. So now I am wondering how to treat that:
a) split pyra-game-buttons into a mouse and a keyboard portion need to test whether that is better accepted.
b) add some button gpio dtb property to the as5013 driver so combine mouse into one device. (like e.g. the jack detect gpio is given to the twl4030-audo stuff)
c) fix userspace. How feasible is that, was anything done to upstream such things? But I guess there is not much awareness of this situation,
a) is easiest, if it works, b) will probably need to duplicate some code from gpio-keys, c) looks it these things will pop up again and again at different places.
Regards, Andreas
On Mo, 2019-01-21 at 07:19 +0100, Andreas Kemnade wrote:
Hi,
yes, the reason for that is because the nubs are in an in-between state :)
The driver we're currently using for the nubs is the same we used on the Pandora. That is only a temporary solution.
The Pandora didn't have clickable buttons, so the current nub driver doesn't use these.
The idea was to write a proper xinput driver so the nubs can be fully used like a normal xinput system, for example a nub.
I'm not sure what the exact state is right now, but I think a basic xinput driver does exist but no one worked on it to make it usable as a mouse, so we're stuck somewhere inbetween.
Hi,
Seems that I am running in "pothole detection mode" on my makesd-created stretch system, pressing the nubs does not cause a mouse button reaction. After some research I found out that the buttons seem to be part of the pyra-game-buttons device and that is treated as keyboard by x11. So now I am wondering how to treat that:
a) split pyra-game-buttons into a mouse and a keyboard portion need to test whether that is better accepted.
b) add some button gpio dtb property to the as5013 driver so combine mouse into one device. (like e.g. the jack detect gpio is given to the twl4030-audo stuff)
c) fix userspace. How feasible is that, was anything done to upstream such things? But I guess there is not much awareness of this situation,
a) is easiest, if it works, b) will probably need to duplicate some code from gpio-keys, c) looks it these things will pop up again and again at different places.
Regards, Andreas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
On 1/21/19 11:00 AM, Michael Mrozek wrote:
On Mo, 2019-01-21 at 07:19 +0100, Andreas Kemnade wrote:
Hi,
yes, the reason for that is because the nubs are in an in-between state :)
The driver we're currently using for the nubs is the same we used on the Pandora. That is only a temporary solution.
The Pandora didn't have clickable buttons, so the current nub driver doesn't use these.
The idea was to write a proper xinput driver so the nubs can be fully used like a normal xinput system, for example a nub.
I'm not sure what the exact state is right now, but I think a basic xinput driver does exist but no one worked on it to make it usable as a mouse, so we're stuck somewhere inbetween.
On PyraOS we moved everything to userspace, so each device can just use the most basic kernel driver, and everything gets turned into highly configurable mouse/joystick/keyboard events by the input daemon.
https://dev.pyra-handheld.com/packages/funkeymonkey-pyrainput (it still needs a bit of work, but the basics are there)
IMO nubs should just show up as their most basic form (two axis, 1 button) and leave all the "smart" stuff to userspace.
Hi,
Seems that I am running in "pothole detection mode" on my makesd-created stretch system, pressing the nubs does not cause a mouse button reaction. After some research I found out that the buttons seem to be part of the pyra-game-buttons device and that is treated as keyboard by x11. So now I am wondering how to treat that:
a) split pyra-game-buttons into a mouse and a keyboard portion need to test whether that is better accepted.
b) add some button gpio dtb property to the as5013 driver so combine mouse into one device. (like e.g. the jack detect gpio is given to the twl4030-audo stuff)
c) fix userspace. How feasible is that, was anything done to upstream such things? But I guess there is not much awareness of this situation,
a) is easiest, if it works, b) will probably need to duplicate some code from gpio-keys, c) looks it these things will pop up again and again at different places.
Regards, Andreas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
you're looking for this : https://dev.pyra-handheld.com/packages/funkeymonkey-pyrainput
cheers, sebt3
Le lun. 21 janv. 2019 à 07:19, Andreas Kemnade andreas@kemnade.info a écrit :
Hi,
Seems that I am running in "pothole detection mode" on my makesd-created stretch system, pressing the nubs does not cause a mouse button reaction. After some research I found out that the buttons seem to be part of the pyra-game-buttons device and that is treated as keyboard by x11. So now I am wondering how to treat that:
a) split pyra-game-buttons into a mouse and a keyboard portion need to test whether that is better accepted.
b) add some button gpio dtb property to the as5013 driver so combine mouse into one device. (like e.g. the jack detect gpio is given to the twl4030-audo stuff)
c) fix userspace. How feasible is that, was anything done to upstream such things? But I guess there is not much awareness of this situation,
a) is easiest, if it works, b) will probably need to duplicate some code from gpio-keys, c) looks it these things will pop up again and again at different places.
Regards, Andreas _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel