X5: Any news about remote support? (RaeNye maybe?)

[moos]

Hi guys, like everyone, I'm wondering if there is something new about remote support for our iaudios.
I know RaeNye(hi) began the port but don't know if there is any update, because the patch on the tracker was just initial support.

We can wondering also about radio support while we are .

Regard, moos

[Bagder]

I know RaeNye(hi) began the port but don't know if there is any update, because the patch on the tracker was just initial support.

The patch in the tracker was not even "initial support". It was a blind attempt that failed.

[moos]

Hi Bagder, thanks, that was I thought, but maybe the author of the patch (RaeNye) have tried something other, lets hope so

[RaeNye]

The patch was indeed a sketch, but it contained most of the needed low-level stuff (e.g., which GPIO pins are needed) that was discovered while RE'ing the preloader.

Basically to create a valid patch you need to mix 2bpp code from H120 with the serial protocol of the H{1,3}x0 remote. Relevant GPIO pins are described both in my patch and in the X5 GPIO wiki table.

The reason I didn't revise it is that I think current LCD code is highly superfluous -- lots of code should be C&P'ed to add a new screen type (e.g., all the drawing primitives) when in fact the only change is how to blit the framebuffer onto the LCD.

I know that the official response would be "so go on and do it!", but as I don't own a remote, I'm more motivated to get my other X5 patches comitted first.

[RaeNye]

Just because I hated to see Bagder deleting my previous rather lame attempt.

http://www.rockbox.org/tracker/task/5634
Moos, are you up to the challenge of testing it?

[Bagder]

Just because I hated to see Bagder deleting my previous rather lame attempt.

Hehe, that's the reaction I needed. Nice to see more work from you!

[RaeNye]

10x
I still refuse to replicate any of the high-level LCD code, BTW.

I think that after releasing 3.0 and comitting most of the waiting patches, RB codebase deserves some refactoring.

I'll be glad to see another feature-freeze for it (and you know I'm willing to complain about the current feature-freeze on every occasion ).

[Bagder]

I still refuse to replicate any of the high-level LCD code

Then by all means write your patch so that you won't have to!

you know I'm willing to complain about the current feature-freeze on every occasion

And you know I can whine back about you not helping us to get out of it...

[moos]

Just because I hated to see Bagder deleting my previous rather lame attempt.

http://www.rockbox.org/tracker/task/5634
Moos, are you up to the challenge of testing it?

Hi RaeNye, cool to see you are here again . I'll happily test your patch when I'll back home, maybe some other users will test before me and give you some feed-backs. If no, I will maybe this night (11H AM here ATM).

Hopefully you made a good job like for your other patches, thx man.

[nicolinux]

A little question about the remote and more particularly about the buttons : when I go to the "View I/O Port" thread (in Debug menu) and when I use the remote, I can see that there is a reaction in "ADC_REMOTE". It seems that all the remote buttons work perfectly.

If it's indeed the case, why would it be impossible to control the player with the remote ? I mean, why could we not use the remote to change volume, or to make a pause ? It would be great because for many actions, I don't really need a screen, just a button...

I hope I'm understandable...

Thank you for your answers.

[RaeNye]

I think I stated clearly that

It has nothing to do with buttons (ADC driver already handles them)

However, the problem is that there's no #define HAVE_REMOTE in config-iaudiox5.h.
Try to add this and check what goes wrong (something should, since the remote LCD is not defined)

[Eriol]

I think I stated clearly that

It has nothing to do with buttons (ADC driver already handles them)

However, the problem is that there's no #define HAVE_REMOTE in config-iaudiox5.h.
Try to add this and check what goes wrong (something should, since the remote LCD is not defined)

From taking a cursory look at the code affected by HAVE_REMOTE and the h100 lcd driver... yikes.  I'll admit I don't know the source tree worth crap (I haven't even bothered to set up my own environment to compile it yet), but (some) of the issues appear to be in converting the h100 lcd driver:

• They defined the global LCD framebuffer as a 1-bit color.  I'm pretty sure my X5 remote has a few monochrome tones (virtually certain in fact, from looking at it REALLY f'n close, they're not doing on/off adjacent pixels, though who knows if they're switching on/off rapidly, though I doubt it).  And the define for allocation has it hard-coded to be a bit, rather than using some type of definition for LCD color depth (which I'm pretty sure DOES exist for the remotes already in one of the config .h files).  I'm thinking either we'll be duplicating most of the driver file for the X5 specifically, with MOSTLY identical functions, or we "generify" it into one driver file, with define blocks for each specific remote model.  As I'm a neophyte here, I have no idea which approach is preferred by the style of the developers.
• They have this weird "tick" define hanging around that seems to be an anti-flicker delay... or something.  This was a cursory look, so I'll admit I don't understand a lot of what's happening there.
• I'm probably missing a host of other issues, since as I said, this is a super-quick look from somebody who doesn't know the project at all.  Layout issues (different resolution remotes) I'm sure also abound, and how to handle them.
• How would I go about testing that patch mentioned above RaeNye?  I assume patching instructions are around (once I set up an environment), but what should I be looking for on the remote to know success/failure?

.

And this is seperate from getting the BUTTONS to work.  The power on delay/not for choosing dual boot works, though after initial boot, all of the buttons are completely non-functional.  You mentioned that the ADC driver handles them, so does anybody know where to start to fully enable them for every part of rockbox?  I said I'm a neophyte, so it's probably pretty obvious to people that know the code, but hey, I wanna use my remote!  ;)  And I have background in programming (I do C/C++ as the main part of my job, though I haven't done integrated systems since University) so I'd like to help out once I get off my lazy ass and set up the build on my own box.

[RaeNye]

From taking a cursory look at the code affected by HAVE_REMOTE and the h100 lcd driver... yikes.  I'll admit I don't know the source tree worth crap (I haven't even bothered to set up my own environment to compile it yet), but (some) of the issues appear to be in converting the h100 lcd driver

My initial attempt (the patch has already been deleted) was to convert the h100-remote, but X5 remote is 2-bit.
The correct code should be some kind of cross breeding the h100 main lcd (for 2-bit grayscale) and remote lcd driver.

I'm thinking either we'll be duplicating most of the driver file for the X5 specifically, with MOSTLY identical functions, or we "generify" it into one driver file, with define blocks for each specific remote model.  As I'm a neophyte here, I have no idea which approach is preferred by the style of the developers.

I pointed out the same thing as well. In fact, this is the main reason I didn't do any high-level code.

How would I go about testing that patch mentioned above RaeNye?  I assume patching instructions are around (once I set up an environment), but what should I be looking for on the remote to know success/failure?

First step: convert the code into a plugin and see if the sample image works.

And this is seperate from getting the BUTTONS to work.  The power on delay/not for choosing dual boot works, though after initial boot, all of the buttons are completely non-functional.  You mentioned that the ADC driver handles them, so does anybody know where to start to fully enable them for every part of rockbox? 

The dual boot is written specifically to do that, since the decision occurs much before anything is initialized in RB.

The #define HAVE_REMOTE (once compiles) will fix the ADC as well.

I said I'm a neophyte, so it's probably pretty obvious to people that know the code, but hey, I wanna use my remote!    And I have background in programming (I do C/C++ as the main part of my job, though I haven't done integrated systems since University) so I'd like to help out once I get off my lazy ass and set up the build on my own box.

What are you waiting for?