Changing The Function Of Buttoms


paddy

Active Member
Joined
Sep 11, 2008
Messages
784
Website
Visit site
Hello

I would like to change some of the button functions on the pandora so i can use the web browser faster and more efficiently ,shoulder buttons to be used as web browser (l)forward / (r) back - pandora start button as web borwser home ,dpad to move through tabs and right anolog to be scroll and buttons ABXY for fullscreen web browser.

On the OS ,i would also like to have mouse button 1 2 3 as the game buttons XYAB ,just keeping them like this would be fine as the web browser setup isn't really needed.

So ,Ed has said this kind of setup is very hard to do and could only be done via an update at some point but i really would have thought this to be an easy tweek more than anything else ,if anyone can point me in the right direction so i can edit the functions for the keys/buttons then a big thankyou.

There are also a few other things i would like to set up as default on the pandora and one of them if the clock speed ,i would like to have 800mhz as the default clock setting when turning on the pandora or at least have it automaticly set to 800mhz once inside the OS or Minimenu ,so i would also like to know if anyone has any ideas on this.

To sum up ..
system default 800mhz

right shoulder button (web browser forward)
left shoulder button (web browser back)
right nub (web browser scroll up down)
dpad (go through links/tabs on the browser page)
X button (left mouse click)
B button (right mouse click)
start button (web browser home)
select button (web browser fullscreen toggle)

thanks

oops ,no not changing the function of your pants !
 
paddy said:
system default 800mhz
Even in Menus?
You don't really care about Battery life, right? :D

Well, I do. I would clock my pandora as low as possible, just to help the battery survive. Of course not, when an app really needs the full MHz Power. :)
 
Last edited by a moderator:
^ ARM is extremely efficient when idle. You can run the device at 800MHz and eventually won't notice a difference in battery life. It depends on your usage scenario.
 
They are hardcoded at the moment. You can possibly remap them using X (xmodmap maybe? not sure)

However, as soon as I receive my Pandora I'll do some kernel patches and try to get my new driver into the OS. It will probably break compatiblity with existing applications which use the kernel interface, but it will be much more standardized and cleaner (also more flexible).
 
I don't know if the Pandora OS is exactly the same, but on my XFCE laptop there is a keyboard hotkey setup feature in Menu>Settings>Keyboard.
 
JayFoxRox said:
They are hardcoded at the moment. You can possibly remap them using X (xmodmap maybe? not sure)

However, as soon as I receive my Pandora I'll do some kernel patches and try to get my new driver into the OS. It will probably break compatiblity with existing applications which use the kernel interface, but it will be much more standardized and cleaner (also more flexible).

Such arrogance ;)

"Differently flexible" is the phrase -- your system and the built in pnd system have different goals, with some overlap. PNDs do things your system does not do, for instance.

No one is competition, people can use all systems or different systems, etc, but don't try to spit at one just because you're making another :)

jeff
 
Last edited by a moderator:
JayFoxRox said:
However, as soon as I receive my Pandora I'll do some kernel patches and try to get my new driver into the OS. It will probably break compatiblity with existing applications which use the kernel interface, but it will be much more standardized and cleaner (also more flexible).
Too late for breaking changes, we really don't want that.

And xmodmap can be used for remapping just fine, there is also ioctl in Linux input subsystem for this.
 
Last edited by a moderator:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:
 
EvilDragon said:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:

So does this mean that we can easily do what Paddy suggested in his initial post?

i.e. remap shoulder buttons etc?

Sorry if the answer is obvious but I'm a total linux noob.
 
Last edited by a moderator:
Mr Loon said:
EvilDragon said:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:

So does this mean that we can easily do what Paddy suggested in his initial post?

i.e. remap shoulder buttons etc?

Sorry if the answer is obvious but I'm a total linux noob.

You can remap the shoulder buttons, but that will most likely break gaming controls, as games expect the shoulder buttons to be mapped as they are.
You could switch around different keyboard layouts before gaming though.
 
Last edited:
skeezix said:
JayFoxRox said:
They are hardcoded at the moment. You can possibly remap them using X (xmodmap maybe? not sure)

However, as soon as I receive my Pandora I'll do some kernel patches and try to get my new driver into the OS. It will probably break compatiblity with existing applications which use the kernel interface, but it will be much more standardized and cleaner (also more flexible).

Such arrogance ;)

"Differently flexible" is the phrase -- your system and the built in pnd system have different goals, with some overlap. PNDs do things your system does not do, for instance.

No one is competition, people can use all systems or different systems, etc, but don't try to spit at one just because you're making another :)

jeff

Wow, you really manage to read something negative in any post..
I didn't even mention PND.

I'm just saying that the way input works currently is BAD. With single event interfaces one can easily have different input per application, I already said this a year ago or so but no-one seemed to care.
You can't expect devs to stick to some libraries only to support input which is well-defined normally, just because the Pandora kernel adds some abnormalities like weird button mapping.
The game controls should not show up as mouse and keyboard but as a joystick device. There is the xorg joystick module which can map back to mouse and keyboard and there is uinput for the same thing (and also working without X which is a lot better for pandora which might not run a full X with some launchers by default).

notaz said:
JayFoxRox said:
However, as soon as I receive my Pandora I'll do some kernel patches and try to get my new driver into the OS. It will probably break compatiblity with existing applications which use the kernel interface, but it will be much more standardized and cleaner (also more flexible).
Too late for breaking changes, we really don't want that.

And xmodmap can be used for remapping just fine, there is also ioctl in Linux input subsystem for this.

What ioctl are we talking about here? The values are hardcoded and the interface was fine until the commit I'm quoting below. The input interface should be presented using event interfaces and no keyboard events or w/e. Then an additional driver to collect it into mouse, keyboard and a joystick driver. This is how it's done on other devices too and the most logical way imo.
Breaking changes are necessary, I'm still writing a blogpost on the whole input issue. Basicly my idea is to rename the kernel driver and add a fallback module for backwards compatiblity.
xmodmap doesn't change the keyboard interface (at least not on my PC), but only the X keycodes which I don't use because I don't even use X.

//Edit: EVIOCSKEYCODE does not work on any of my own input devices so for now I'd just assume it will probably not work on Pandora neither.

EvilDragon said:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:

Maybe because of this file:

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=blob;f=arch/arm/mach-omap2/board-omap3pandora-input.c

Code:
static struct gpio_keys_button gpio_buttons[] = {
  GPIO_BUTTON_LOW(110,    KEY_UP,         "up"),
  GPIO_BUTTON_LOW(103,    KEY_DOWN,       "down"),
  GPIO_BUTTON_LOW(96,     KEY_LEFT,       "left"),
  GPIO_BUTTON_LOW(98,     KEY_RIGHT,      "right"),
  GPIO_BUTTON_LOW(109,    KEY_PAGEUP,     "game 1"),
  GPIO_BUTTON_LOW(111,    KEY_END,        "game 2"),
  GPIO_BUTTON_LOW(106,    KEY_PAGEDOWN,   "game 3"),
  GPIO_BUTTON_LOW(101,    KEY_HOME,       "game 4"),
  GPIO_BUTTON_LOW(102,    KEY_RIGHTSHIFT, "l"),
  GPIO_BUTTON_LOW(97,     KEY_KPPLUS,     "l2"),
  GPIO_BUTTON_LOW(105,    KEY_RIGHTCTRL,  "r"),
  GPIO_BUTTON_LOW(107,    KEY_KPMINUS,    "r2"),
  GPIO_BUTTON_LOW(104,    KEY_LEFTCTRL,   "ctrl"),
  GPIO_BUTTON(100, EV_KEY, KEY_LEFTALT, 0, "alt"),
  GPIO_BUTTON_LOW(99,     KEY_MENU,       "menu"),
  GPIO_BUTTON_LOW(176,    KEY_COFFEE,     "hold"),
  GPIO_BUTTON(108, EV_SW, SW_LID, 1, "lid"),
};

Thins went wrong here:

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commit;h=c51ef67c1ec5c4e31e668eb1f481a8f1080ad108

input: change game button scancodes to KEY_KPx
Craig et al. decided to drop SNES layout, using independend keycodes instead.

I also complained about it back then and I was told that you, EvilDragon, also requested these changes.

Mr Loon said:
EvilDragon said:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:

So does this mean that we can easily do what Paddy suggested in his initial post?

i.e. remap shoulder buttons etc?

Sorry if the answer is obvious but I'm a total linux noob.

Only works for X apps and those applications which do not use the kernel interface (meaning it's not working for all applications, but only a few)
 
Last edited by a moderator:
JayFoxRox said:
And xmodmap can be used for remapping just fine, there is also ioctl in Linux input subsystem for this.

What ioctl are we talking about here? The values are hardcoded and the interface was fine until the commit I'm quoting below. The input interface should be presented using event interfaces and no keyboard events or w/e. Then an additional driver to collect it into mouse, keyboard and a joystick driver. This is how it's done on other devices too and the most logical way imo.
Breaking changes are necessary, I'm still writing a blogpost on the whole input issue. Basicly my idea is to rename the kernel driver and add a fallback module for backwards compatiblity.
xmodmap doesn't change the keyboard interface (at least not on my PC), but only the X keycodes which I don't use because I don't even use X.

Well - that is possible without breaking anything, so no big deal. Move the keys outside the kernel and use /etc/keymap-extension-2.6.map and that's it.

input: change game button scancodes to KEY_KPx
Craig et al. decided to drop SNES layout, using independend keycodes instead.
I also complained about it back then and I was told that you, EvilDragon, also requested these changes.

The also thing I requested was that the gaming controls are NOT keys at the same time.
Back then, we had Up, Down, Left and Right mapped to Cursor Keys AND joystick directions as well as ABXY to joystick buttons and keyboard keys.
That did cause a lot of trouble. UAE4ALL wasn't working properly anymore, DOSBox Mapping didn't work, SuperTux acted up.
That's why we decided to scrap that and now the gaming controls are only mapped to keyboard keys.

The other thing was that I suggested button mapping for ABXY. I have nothing to do of where that mapping takes place, as I have no idea about where this all happens in Linux.

Only works for X apps and those applications which do not use the kernel interface

Well, part of our layout is done using /etc/keymap-extension-2.6 (no idea why only a part).
I have no idea if you could change that layout there, too.

(meaning it's not working for all applications, but only a few)

I'm pretty sure Paddy has not a single app on his Pandora that he runs outside of X which uses a mouse... so much for the "few"
 
Last edited:
JayFoxRox said:
The game controls should not show up as mouse and keyboard but as a joystick device. There is the xorg joystick module which can map back to mouse and keyboard and there is uinput for the same thing (and also working without X which is a lot better for pandora which might not run a full X with some launchers by default).
What problem are you going to solve with this? With the X joy module/uinput you will get duplicated events, programs will see both joystick and keyboard events and it will confuse the hell out of them. Sure they can be patched, but why create additional work for everyone?
You seem to emphasize X-less mode but note it doesn't even exist currently, X is always running. Feels like you want to suit your own needs without thinking about everyone else.

JayFoxRox said:
The values are hardcoded and the interface was fine until the commit I'm quoting below. The input interface should be presented using event interfaces and no keyboard events or w/e. Then an additional driver to collect it into mouse, keyboard and a joystick driver. This is how it's done on other devices too and the most logical way imo.
Somehow I'm missing list of benefits from your approach, "most logical way imo" is not really convincing you know. Sure this would give ability to remap keys and still have some static mappings that don't change at the same time, but then there is event duplication problem. You might say it's their problem if they're affected by duplicate events, but there are quite a few of them and it's not worth the increased porting effort and diff size from PC versions.

JayFoxRox said:
//Edit: EVIOCSKEYCODE does not work on any of my own input devices so for now I'd just assume it will probably not work on Pandora neither.
If you don't know how to use it it doesn't mean it doesn't work.

JayFoxRox said:
EvilDragon said:
In fact, we USE xmodmap and standard Linux keyboard layout files for the keyboard.
Why the heck do you think it's hardcoded? :eek:

Maybe because of this file:

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=blob;f=arch/arm/mach-omap2/board-omap3pandora-input.c
And your suggestion is?

JayFoxRox said:
Mr Loon said:
So does this mean that we can easily do what Paddy suggested in his initial post?

i.e. remap shoulder buttons etc?
Only works for X apps and those applications which do not use the kernel interface (meaning it's not working for all applications, but only a few)
You probably mean the most? The kernel interface is not meant to be used by anyone directly, same as it is on PC (it's typical user is X). It was wrong to make it user readable, we should've left it root only, like every Linux distribution does..
 
Last edited by a moderator:
*First paragraph, ran out of quotes*
X-Less mode was dropped? When did that happen?
And no, a better input system will help all devs and users, not only me.

notaz said:
Somehow I'm missing list of benefits from your approach, "most logical way imo" is not really convincing you know. Sure this would give ability to remap keys and still have some static mappings that don't change at the same time, but then there is event duplication problem. You might say it's their problem if they're affected by duplicate events, but there are quite a few of them and it's not worth the increased porting effort and diff size from PC versions.

This would give developers the freedom to detect the input as anything they want - let it be a mouse, keyboard, raw input events or just a joystick device AND not hardcoding it could possibly mean doing it per application.

notaz said:
If you don't know how to use it it doesn't mean it doesn't work.

Right.. I tried a few tutorials and none of them worked. Might be my kernel - I don't know, however, I'm absolutly sure that it is not my fault. Besides that, linux journal also states that it doesn't always work:
Be aware that keycode ioctl functions may not work on every keyboard—that USB keyboard is an example of a driver that does not support variable mappings.
http://www.linuxjournal.com/article/6429?page=0,1

If it works on Pandora - fine, still a bad way to do it imho.

notaz said:
And your suggestion is?

- Provide raw input events from the kernel, similar to the previous/first drivers (1 interface with only BTN events, 2 interfaces with only ABS_X and ABS_Y)
- In userspace make anything you want from them (A mouse, keyboard and joystick event interface, seperatly controlled using sysfiles for examples)
--> Apps will not detect raw input events unless they really want to
--> Apps can then decide which events they need (probably through PXML, in the worst case by writing to sysfiles themself)

notaz said:
You probably mean the most? The kernel interface is not meant to be used by anyone directly, same as it is on PC (it's typical user is X). It was wrong to make it user readable, we should've left it root only, like every Linux distribution does..

Yep, but if we had a joystick input event that could be used used as interface in applications.
 
Last edited by a moderator:
JayFoxRox said:
- Provide raw input events from the kernel, similar to the previous/first drivers (1 interface with only BTN events, 2 interfaces with only ABS_X and ABS_Y)
- In userspace make anything you want from them (A mouse, keyboard and joystick event interface, seperatly controlled using sysfiles for examples)
--> Apps will not detect raw input events unless they really want to
--> Apps can then decide which events they need (probably through PXML, in the worst case by writing to sysfiles themself)
So is this some custom interface you are doing? How it is supposed to go per app and not be system global?

EDIT: I agree it would be best for nubs to always stay in abs mode, but if you do some X plugin or input wrapper for it to also become a mouse, that would still interfere with games that don't need this. The games would still have to ask whatever is doing mouse part to stop, which is not that much better that current 'modes' thing.
 
Last edited by a moderator:
Im content with with the way controls are working. Most apps are able to work with keyboard only type events.
Some might need joystick buttons, which we have a interface to control the setting with.
Nubs with the latest changes can support mouse, buttons, or absolute modes.

Personally I dont care hows it coded or if its in the kernel/userspace, the fact is the current method works and all the modes can be configured. I dont want to have to handle 2 events for one input action, like was mentioned it causes issues.
 
Ill ask again can i or will i be able to change my button and nub cfg to something of my choice now or in the future ?
 
Back
Top