Cowon D2

[shotofadds]

If you make changes to a particular plugin's mappings, upload your patch to a new task on Flyspray so that someone with commit access can get your fixes into SVN. Thanks!

(but please don't raise D2 bug reports on the tracker - it's not a supported target yet)

[splitsch]

Hello!
I've downloaded the last *.zip of this fw.

How can I enable it, in dualboot with he existing firmware?

Thanks

[martink]

Look here:
http://www.iaudiophile.net/forums/showthread.php?t=20661&page=4
at 04-10-2008, 10:10 AM

[JdGordon]

why the heck are you linking to iaudio forums to a post which links back to this thread?!

[martink]

Excuse me, but for me the "step by step installation" from Hupy seems to be useful.

[Llorean]

Or you could just link him to the information in our wiki. The information he could've found if he'd searched like required to by the guidelines. http://www.rockbox.org/twiki/bin/view/Main/CowonD2Info

[Shady]

oops! Sorry andiator, guess I've mixed up the controls. They are flipped now, i mean the up is down and the left is right Anyway it is better now than before

[andiator]

Ok, updated rockbox.zip again.

[JdGordon]

shotofadds: I dont think I have your email so ill comment on the touchpad test plugin here...

its more of a general issue than anything for the actual plugin..
1) use SOURCES for hhte #ifdef HAVE_TOUCHPAD instead of wrapping the whole .c file in them
2) always add functions to the end of the plugin api or you break builds unless a full rebuild is done.
3) "intptr_t button_data;   /* why intptr? */"  because void* and int are different sizes on 64bit sim builds, so this stops the warnings
4) there is no way to switch between stylus and button mode?

other than that, it looks good...

http://www.pastebin.ca/1003385 for those having no idea what im talking about

[shotofadds]

As it's a test_* plugin it'll rely on people manually adding it to SOURCES, so I'll remove those HAVE_TOUCHPAD ifdefs - they're rather pointless.

I don't really understand "add functions to the end of the plugin api or you break builds unless a full rebuild is done". Surely the very act of updating plugin.h causes all plugins to be rebuilt?  (but that's rather off-topic for this thread I guess...)

As for the intptr_t, I wasn't sure why button_get_data returns a pointer type at all - surely it's just a 32 bit int (int32_t or somesuch?)

I'll add a switch for the stylus mode (can you suggest a button mapping for the m:robe?) and then we're in business.

This plugin has already shown up a couple of issues on the D2:

1) Touching on/near the 'line' between two areas causes jitter between the two adjacent rectangles. This causes a stream of distinct button presses.

2) Small, slow movements are shown with a fast update rate, but faster movements are shown with a really slow update rate (is this the HZ/5 thing?)

3) A continuous movement of the stylus seems to work fine, but when used for individual button presses I occasionally get a 'random' extra button event, before the actual press.

Do you see any of those things with the m:robe?

[JdGordon]

void* is usually used to just say "random data... no real type.." but yeah, we could have used int32_t or something.. but its there now..
yes, plugins get rebuilt, but there is a mechanism where if you only update the rockbox.target file plugins of older revisions will still load if the API versions are compatible... adding funcitons in the middle of the struct breaks that.

BUTTON_RC_MODE would be ideal...

1) yeah, i noticed that also, i think we need to add a error margin around the joins, or something
2,3) not realy sure what your mean...

I havnt tested the plugin yet and wont be able to till next week unfortunatly.

[saratoga]

I don't really understand "add functions to the end of the plugin api or you break builds unless a full rebuild is done". Surely the very act of updating plugin.h causes all plugins to be rebuilt?  (but that's rather off-topic for this thread I guess...)

I think that since files include headers, rather then headers including other files, changes to .h files do not propagate down to the files that include them automatically. 

[shotofadds]

I think that since files include headers, rather then headers including other files, changes to .h files do not propagate down to the files that include them automatically. 

I don't think that's right, eg. a change to plugin.h causes "make rocks" to rebuild every plugin.

But then again, if there's a "best practise" for this kind of thing, let me know as this is the first time I've done any changes in this area.

[kugel.]

About the plugin API stuff. The plugins get rebuilt, sure, but only if you make a full build.

If you only do "make bin", the plugins are not built.

make bin is very much faster and is very usefull, especially when plugins/plugin api do not change.

The version number is just to make older plugins work with newer rockbox.target files.
So, if you put new functions to the end, old plugins will still work. If you put the into the middle, old plugins will mess up.

To make old plugins work, you need to put it to the end, until you choose to increase the plugin api version number. Then plugins will error and need to be rebuilt. That's allways a good situation to reorganize the api functions.

* kugel. hopes that was correct.

[shotofadds]

Sounds about right. Here's version 2 of test_touchpad, which should address those comments: http://www.pastebin.ca/1004398

jdgordon: I noticed one more thing: in stylus mode, the button_data doesn't seem to contain the x/y values for BUTTON_REL events. Is that intentional? It's not very useful if so...

And no, I don't know why I didn't use the tracker for this patch...