Cowon D2

[shotofadds]

As I understand it, the Rockbox UI already averages the battery measurements. So there's no need to do that inside the driver.

I have no particular opinion on which battery-reading method is best: we could use either of the two values from the PCF, or adc_read(1). I just used the simplest to work out, as I don't think it's too critical at the moment.

Maybe we should do some more tests....

[JdGordon]

hey,
So I've started fiddling with the touchpad on the mr500 and have started working on the touchscreen button keymap. I've split the screen up into a 3x3 grid so we have 9 buttons (I've been told the D2 should be big enough to do the same).

attached is the patch which is mostly mr500 specifc but hopefully shows how I tihnk the touchpads should work...

there is a function set_touchpad_mode() which lets screens change between stylus and button mode. in button mode the regular leymap files will be used. in stylus mode the screen will have to figure out what the user pressed....

for the keymaps would it make sense to use one file for both touchpad targets, although it looks like we will have to add a bit of #ifdeffing for the 2 targets because the mr500 only has one real button while the d2 has 4 (the remote keymap for the mr500 will stay in a seperate file to make it a bit cleaner)?

as for the mappings themselves... this is what I have so far (and from my 30s of testing it seems to work)
up/down is top and bottom center. select is middle. cancel is bottom right, menu is top left, contect menu is hold select


edit: attachment updated to include sim fixes... the numpad buttons are used for the 9 touchpad buttons (D2 sim probably wont ocmpile with this change though....) and the sim will convert mouse -> button depending on the touchpad mode like the target should.

[shotofadds]

Yep, the D2 screen should be big enough for 9 'button' areas, assuming you don't have MASSIVE fingers.

I'm not sure if combining the keymap files is a good idea - for example it should also be possible to use the D2's physical buttons to navigate menus and operate basic screens. IMHO that could lead to a huge mess of #ifdef's if and when any more touchscreen targets come along.

I think all screens (& plugins) should default to 'button' mode unless they explicitly ask for 'touch point' mode, so I'm not sure there's any need for a setting in the menus.

I'll try to concoct a D2 touchscreen driver to work with this patch over the next few days. I'm having some trouble with interrupts from the PCF chip at the moment (it all stops working after ~30 seconds) so I might need to do some creative thinking first...

ps. (minor niggle) doesn't Rockbox generally use UK English? BUTTON_CENTER grates slightly here.

[JdGordon]

well, the D2 only has 4 real buttons right? and the mr500 only has 1, so I dont think the extra ifdefs would be such a big problem (certainly less painful than keeping the touchpad keymaps in sync, which they should be).

yeah, screens should default to setting the button mode unless they are specifically set up for stylus mode.
The lists though could do with a setting to choose which mode (seen as both work now), and the wps would also need a setting (I have an idea how to do stylus mode there, and there is a patch somewhere, but its being held out of svn untill one of the targets gets playback going).

as for CENTER/RE, yes, I couldnt remember which is which... I prefer UK english also, I'll change it.

[Llorean]

Possibly "Touchmaps" should be kept separate from "Keymaps" in some way, so the touchscreen can be kept in sync, but the buttons can be handled independently?

[JdGordon]

not sure what you mean by that...

What I was saying is that we should force touchpad targets to have a common button mapping for the touchscreen to make everything easier.. (1 manual, 1 keymap file, easier to move between targets, etc). sure they will all have differences, but we can either use #ifdef TARGET, or use the keymap system to check for touch buttons first then move to the target keymap.c file for its real buttons (which I don't think is needed while we only have 2 touchpad targets...)

[Llorean]

Your second suggestion is more or less what I was trying to propose. I think it's probably not a bad idea to assume we'll have more touchscreen targets (PDAs if as-an-app happens, for one), so treating the touchscreen controls as something completely separate from the keymap defines (since there's really only ever going to be one set of maps for the touchscreen, while physical buttons will always vary by target).

[linuxstb]

as for CENTER/RE, yes, I couldnt remember which is which... I prefer UK english also, I'll change it.

The convention is to use US English for C symbols, and British English for user-visible text.  So in this case it should be BUTTON_CENTER (but referred to as "centre" in the manual and any LANG strings).

[JdGordon]

did a bit more work on this today.

keymap-touchpad.c is shared and only deals with the touchpad codes.. what should happen is the action code goes through that file, then if the button hasnt been found it goes to the tartgets keymap file.. seems to work but not fully tested.

[Yeeze]

I am not sure but I think when talking about the controls, we might also consider "gesture" support...

There is no need to implement the recognition now, but we should think about the defines to keep them in the keymap or so...

[Llorean]

Rockbox already has the ability for actions to be defined as "one  button preceded by another button" as far as I know. This should at least allow for very simple gestures (center to left, center to right, top-middle to center) with the 3x3 grid style button map, with a lot less work (I would *guess*) than a complex full gesture system would require, and could probably cover the majority of jobs you'd want to do with it.

[cybergrind]

IMHO: we have combinations of two buttons (if you about keymaps), but, maybe we need more (eg. left->right gesture should contain mid-left, mid-center, mid-right or top-... or bottim-...).
more simple method - define gestures like vectors, not combinations of two or more buttons, when we have start point, angle, end-point - in simple gestures.

and conceptions with TS-buttons didn't contain such features as drag-n-drop, selection of item or selection of area... but it more simple in implementation =)

[JdGordon]

the grid buttons are more being used to quickly get the touchpad working in all screens. If gestures happen they would most likly be done in the stylus mode, although depending on a few things simple left<->right and up<->down could work in button mode.

[Llorean]

I think, for example, in the WPS, anything "left center" could be "seek backward" while a gesture from "center center" to "center left" could be "previous track". With a 3x3 grid, you have 12 intersections between the grid blocks. As long as you actually can treat is as _PRE so that going from one block to another works, you can add a lot of "gesture"-like functions.

[JdGordon]

the _PRE stuff shouldnt be a problem at all... I'm more concerned with how offten the touchpad sends its buttons... I think it might actually be too slow to work reliably...

also diagnal gestures are almost certainly out of the question using this method...

shotofadds: (and really anyone i guess)... does this look workable and should it be commited? and should the BUTTON definitions be put in button.h instead of button-target.h to make sure all touchpad targets setup the correct button defines?