Cowon D2

[isanggon]

I tried touch screen patch. It worked fine with FREQ>>23 without 2-line problem on my device.

shotofadds// Okay, I'll try other value, for test

[shotofadds]

I don't know if this is due to some other mod but it seems to me that a mod in other files causes the problem in the lcd driver to reappear. How is it possible?

D'Oh! Of course, we can adjust the delay all we like, but behaviour will still vary if an interrupt (IRQ) occurs while sending commands to the LCD..

I suggest updating lcd_write_reg() so that it reads:

Code: [Select]

static void lcd_write_reg(unsigned char reg, unsigned short val)
{
    int irq_level = disable_irq_save();
    ltv250qv_write(0x740000 | reg);
    ltv250qv_write(0x760000 | val);
    restore_irq(irq_level);
}

That might improve things.

[FranzD2]

@shoto

1) I just tried test_fps and i saw no differences, if i press or don't press the screen, the values are the same.

2) I tried disabling irq in lcd_write_reg + using FREQ>>24 and i saw one line repeated, with a value of 23 things seem to work better, i'll test it better tomorrow all day at work.

@all

Please if you want to try the touchscreen patch then use the second one, i've adjusted a value that caused problems in the first one.

[shotofadds]

1) I just tried test_fps and i saw no differences, if i press or don't press the screen, the values are the same.

Really? Check the value displayed at the top: with a plain SVN build this shows either 153.5fps or 158fps normally (at 48Mhz), but goes down to around 120fps if I continually circle the screen with my finger - that's a massive amount of CPU usage attributed to the touchscreen. That's why I'm concerned about adding any more complexity to the button driver, and trying to look at doing things a different way.

NOTE: Don't do any speed testing if you are uploading the build using tcctool, sometimes this can give rather different results (and I currently have no idea why that's the case).

btw. I'd also recommend looking at the test_touchscreen plugin, you can use it to see which calibration values work best (for me SVN is rather more accurate than your patch...)

2) I tried disabling irq in lcd_write_reg + using FREQ>>24 and i saw one line repeated, with a value of 23 things seem to work better, i'll test it better tomorrow all day at work.

Yes, FREQ>>23 plus disabled IRQs seems to work fine for me too. Hopefully we've cracked it this time.

[FranzD2]

1) About test_fps's results CPU: 48 Mhz
1/1 is 140.0 fps (main lcd update)
1/4 is 534.0 fps (main lcd update)
these values don't change when i use the touchscreen even if i circle with my finger or press multiple buttons, i tried several times but they don't change.

2) I tried disabling the busy wait loop but at the moment it is not a good idea, First: there are incorrect presses, Second: i see repeated lines again (only with the loop disabled). I think that this cycle is essential if we want to always read correct value, so we could try to optimize other things (BTW: a busy wait loop should be also placed when reading battery values)

3) I tried the touchcreen testing plugin, it seems that the empiric calibration is not so bad,

EDIT:

In touch_to_pixels try to modify "x = val_x / 3.5;" -> to -> "x = val_x / 3.1;"

I forgot to include this fix in the second patch....

however the old calibration does not work with my patch (and i don't know why) so i had to replace it with some rough operation, maybe you can find a better solution

[dragongod]

I'm confused. Justnow I started a v19309 and there got the "famous" problem: one (or two?) line(s) of top appeared at the bottom. But after I shut it off and power on again, It's just all OK.  I tried to reboot for another 3 times, still all OK. Only the first time got that problem.

it's a 2G D2 without DMB. i will try other values besides >>23 ,and try to make the problem reappear with the value 23.

EDIT:
I tried 22 23 24. 22 would cause the problem, and 23 24 would be OK. But I can't reappear that problem with 23...

EDIT2:
Oh here come again. 23 is unstable for me. Sometime it's OK and sometime it gets the problem. maybe i should use 24.

[Yeeze]

I'm confused. Justnow I started a v19309 and there got the "famous" problem: one (or two?) line(s) of top appeared at the bottom. But after I shut it off and power on again, It's just all OK.  I tried to reboot for another 3 times, still all OK. Only the first time got that problem.

I think someone said, that the problem only appears when the original cowon firmware powers the display on right before the rockbox boot...

[ThibG]

I just tried again and... the screen doesn't turn on. If I hold the power off "button" a few seconds, I can turn on my D2 again (under the Official Firmware).

[shotofadds]

I just tried again and... the screen doesn't turn on. If I hold the power off "button" a few seconds, I can turn on my D2 again (under the Official Firmware).

You're going to have to give me a bit more information than that. What were you trying to do?

[ThibG]

It's because of me... I have made a little script to update the local svn copy, rebuild the whole thing, and upload it to the D2... I didn't notice that the bootloader moved from ./bootloader/bootloader.bin to ./bootloader.bin
So, it works, and pretty well
I tried to boot 25 times, it worked the 25 times
The screen worked fine most of the time, but not everytime (I then booted on the OF, and rebooted to rockbox, it fixed the two top lines issue).
No weird sound when playing music, gapless playback, and all the good things of rockbox.
I played elephants dream, it worked very fine, except the first seconds.

There is a few seconds before the first music, during which rockbox "hesitate" about the remaining/total time of the song.
The date is completly off
Rockbox doesn't want to shut down if connected on USB
Rockdoom is stuck at "Starting Graphics engine"


I didn't tried the USB support.
One other (really, really, really minor) thing I have noticed is the shutdown message, that talks about low battery...

[3amsleep]

1.- Franz patch is working FLAWLESSLY for me!, GREAT JOB! 

2.- i noticed something, maybe its normal but, when the screen "shuts down" it dosnt actually, i can still see VERY faintly whats going on. i guess its just the backlight going to "0" and the screen is still working... i think this could be potentialy eating a nice chunk off the battery.

3.- i noticed regular skips on some of my ogg tracks, audio skips always in the same position and with same "skip duration" on the same tracks. (each track has its own skipping position and duration)

4.- first post here!, hope i can help with the proyect. i been trying to learn C but i still cant understand 60% of whats going on inside the code XD,  i teached myself with cprogramming.com C tutorials, but i think thats not going to be enough... can anyone reccomend another good web resource/tutorial? .

[FranzD2]

Hi all!

I used rockbox on my D2 for some days and I noticed these problems,

1) The touchscreen stopped working two times
2) While i was listening Pink Floyd, the music stopped  :'(, the touchscreen and all the other buttons stopped working
3) While i was listening Claudio Cordero, the music stopped and the player turned off

Anyone noticed some of these?

[3amsleep]

Hi all!

I used rockbox on my D2 for some days and I noticed these problems,

1) The touchscreen stopped working two times
2) While i was listening Pink Floyd, the music stopped  :'(, the touchscreen and all the other buttons stopped working
3) While i was listening Claudio Cordero, the music stopped and the player turned off

Anyone noticed some of these?

yeah i noticed that too, it has happened to me like 2 times also, but i think its just the unreliable nand driver.

i also noticed sometimes if you are using a m3u playlist and you skip the tracks too fast, the player will crash on some tracks.

[FranzD2]

Yes I think so too, i also noticed some "Bad Checksum"

I have some improvement in the touchscreen patch but I'm waiting to test it better, the actual patch has still some (very rare) error.

[shotofadds]

Once again I'll re-iterate that the filesystem driver is unreliable and will lead to errors (which may include crashes - ie. unresponsiveness) during playback. There is a very good reason why the wiki has said that for at least the last 6 months, so until further fixes go in please don't report these kind of issues. It really doesn't make any difference what kind of music you're listening to.

Touchscreen improvements will come, but I can't commit your patch until a solution has been found to the CPU usage issue. I plan to look at it after the Xmas break, but it's very much a second priority after the filesystem driver.

I'm currently working on a PC-based simulation of the NAND driver (in conjunction with a large amount of raw data obtained using gevaerts' USB work) and hopefully that will yield some results soon. Unfortunately the main problem is that I have less and less time to spend on Rockbox work these days.