Support and General Use > Hardware

X5: Itching to create a patch that shuts the LCD off when backlight is off.

(1/6) > >>

jhMikeS:
I've read a request on another thread about shutting down the LCD panel when the backlight is off. Some code is in place already to facilitate this and I almost know how to procede on the X5 (the only player I have right now). Is it even worth it?

I'm new to just about EVERYTHING as far as what each file is for in rockbox, cygwin, UNIX shell, the utilities used for building rockbox (cvs, gcc, etc.), little familiarity with the MCF5249 and HC66773R but I believe I'm making progress in my knowledge.

The MFC5249 User's manual is quite daunting at 450 pages and the HD667733R at 133 pages too. I just need a little help!

I do have some questions (better asked on IRC?):
The LCD command register and data register are listed in the twiki as 0x20008000 and 0x20008002 repectively but the driver writes to 0xF0008000 and 0xF0008002. Why this descrepancy?

How is the mapping of the LCD chip to CPU memory addresses accomplished? Is it hardwired on the board or done in the software somewhere? Which lines? Knowing this would help my understanding of the CPU greatly.

Which interface does the LCD driver use? I know it's 18-bit but serial or parallel?

I still need to get my setup completed and learn how build the sources for the X5 port but the wiki is down and I'm left with cached pages on Google which is slowing me down a lot.

Not quite entirely related:
Will full 18-bit color ever be supported? The driver expands colors from 5-6-5 to 6-6-6 before writing them to the gram. It appears that color values would have to be longs and not ints and that would mean changing a lot of code (not that I wouldn't take it on). I've been warned about changing everything!

Llorean:
Yes, your best bet is to ask in the IRC channel.

The only one of these I *might* be able to answer is relating to the 16/18 issue. I do believe 16 bit is used even on 18-bit targets simply because it's faster. 18 bit is possible, if I understand correctly, but would be considerably slower.

Oh, and shutting the LCD off won't gain *much* since all the drawing calculations have to be done anyway to keep the screen updated, as the various threads don't know the whole screen's state.

jhMikeS:
All the code for writing to gram would be skipped while the display is off though. There's quite a bit of writing going from the screen buffer to gram. You're saying this extra step doesn't consume much power? Additionally , how 'bout shutting the chip down entirely when (sleep or standby) not in use? The powerup sequence doesn't appear to take too long.

As far as full color support goes, I seriously wouldn't mind *gasp* wasting the memory and just using 32 bits per pixel for simplicity and speed. The memory requirement would only be doubled. It can also be dithered easily enough if someone wants super high quality.

Llorean:
Well, tests on another color player showed that shutting off the screen entirely, but leaving the drawing routines as-is, didn't affect things significantly (if I recall.) There was some increase in battery life, but not as much as was hoped.
Though to be honest, at the time they were hoping for a LOT. And I don't really recall hard numbers as to the actual improvement.

As for doubling the memory used by the screen, you'd also have to double the memory available for the WPS buffer. I can't really see 18-bit color offering a major improvement for the while playing screen or for the menuing system. Maybe for image-viewing though. But that's just me.

jhMikeS:
It can certainly be tried-out and would be educational for me. For the X5 it looks like some rather simple changes to the lcd and backlight files.

A parallel API to use full native color depth for image viewing (and maybe eventually video) might be worth working on.  Only one additional function call that expects 24 or 32 bit pixel data (with optional dithering) should be needed to start out. How about lcd_blit_ex? It could be used concurrently with existing functions when extra color quality is desired.

I'll get set up on IRC and not get too much heavier here.

Navigation

[0] Message Index

[#] Next page