Changing The Function Of Buttoms

[paddy]

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 !

 

[fusion_power]

system default 800mhz

Even in Menus?
You don't really care about Battery life, right?

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.

 

[mali]

^ 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.

 

[JayFoxRox]

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).

 

[Aninhumer]

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.

 

[skeezix]

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

 

[notaz]

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.

 

[EvilDragon]

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

 

[Loon]

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

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.

 

[EvilDragon]

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

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.

 

[JayFoxRox]

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).

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.

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

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

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.

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

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)

 

[EvilDragon]

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"

 

[notaz]

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.

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.

//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.

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

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?

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..

 

[JayFoxRox]

*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.

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.

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.

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)

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.

 

[notaz]

- 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.

 

[Pickle]

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.

 

[paddy]

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 ?

 

[j.pickens]

Sounds like the answer is yes.
Though I am unclear on the specific procedures necessary.