LCD screen for your dockstar (cheap! <$5)

Diff patch for st2205term for ax206 frame support. Seems like the uploaded copy to minus.com is gone as guest uploads have a time limit.

ax206term Wrote:
-------------------------------------------------------
>Could you list lsusb output? Do you have a udev rule getting in the way? You >need ID 1908:0102 in the lsusb output.

You right. It was udev rule problem. Now it works, partially.

./st2205term --dpf --font=giant --keyboard=/dev/input/event3 --keymap=./us.kmap
INFO: using fontdata from file /tmp/st2205term-0.11/fonts.txt
INFO: picframe selection automatic (polling /dev/disk/by-id)
load_kmap(./us.kmap) - loading key defintions
load_kmap(./us.kmap) - 71 key defintions loaded
load_font(/tmp/st2205term-0.11/fonts.txt,3) - loading font defintion
Found AX206 DPF
Got LCD dimensions: 128x128
create_terminal 128x128 pixels => 14x8 chars
rote_vt_forkpty: command='/bin/bash --login' PID=-1
INFO: successfully connected to picframe
Opened device /dev/input/event3 (/dev/input/event3) =>   USB Keyboard

I can see characters on the screen, but there's no terminal. Is this "rote_vt_forkpty" has something to do with librote? I can't test it on dockstar because I have only PC.

And another question. Does someone tested non-english kmaps?

@petergun
Did I get it right: you have two different ax206 dpfs? Is one of them working?
If not, please upload a dump of the original fw. I'll see what I can do,

Try to re-flash the original fw with ProgSPI (available here). If ProgSPI complains about unknown flash, please post the output.

superelchi

neon Wrote:
-------------------------------------------------------
> I can see characters on the screen, but there's no
> terminal. Is this "rote_vt_forkpty" has something
> to do with librote? I can't test it on dockstar
> because I have only PC.
I am fairly certain this behavior is consistent across st2205 and ax206 frames and displaylink displays under st2205term as I didn't modify any of the code around rote_vt_forkpty which is part of rote. The dockstar doesn't have a console so this line works correctly. But on the PC, it doesn't. I'm not sure what can be done about this perhaps petergunn will know something.

neon Wrote:
-------------------------------------------------------
> I can see characters on the screen, but there's no
> terminal. Is this "rote_vt_forkpty" has something
> to do with librote? I can't test it on dockstar
> because I have only PC.

rote_vt_forkpty: command='/bin/bash --login' PID=-1

This means that the command that runs in the terminal failed to start. Basically "/bin/bash --login" failed - either bash is somewhere else like /usr/bin/bash or its the "--login" parameter causing problems because you are root during startup.

You can specify a different shell and/or options using the --command=<command> option:

i.e. if you have dstat installed you can get an output a bit like lcd4linux with the bundled 'stats' program...

st2205term --command="./stats -t=./template.txt" ...     # note: best to use the full path to stats & templates.txt

>
> And another question. Does someone tested
> non-english kmaps?

Not that I know of but they should be straightforward to create. The keymap file is similar in format to Android Key Character Maps which should be quite easy to modify.

# keyname       ev-code  lower   shift   ctrl    alt
A                  30     'a'     'A'    0x00    0x00
B                  48     'b'     'B'    0x00    0x00
C                  46     'c'     'C'    0x03    0x03
D                  32     'd'     'D'    0x04    0x04
...

ev-code: the event code that comes from the USB keyboard device when the key is pressed. Just swap the values around in the file if its mapping to the wrong character. For unknown mappings the easiest way to find the ev-code is to hack evkey2linuxkey() in st2205term.c and output info about unknown events to a file, run st2205term then press they key thats not mapped, then examine the file :-)

-PG



Edited 2 time(s). Last edit at 04/29/2012 08:02AM by petergunn.

FYI: st2205term-0.11.tgz has been uploaded

I added a mak-dpf script that builds ax206term. It tries to download the dependent libraries and files automatically.

I haven't tested it so I've left the prior version there as well.

-PG

I forked Andre's Samsung Frame Framebuffer driver. ax206fb.c is done and can be loaded as kernel module, and /sys/kernel/debug/ax206fb is created. A simple test with fbset

fbset -fb /dev/fb1 -i

mode "128x128"
    geometry 128 128 128 128 16
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : AX206 DPF Frame 
    Address     : 0xffffc9002286a000
    Size        : 2097152
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 1
    LineLength  : 0
    Accelerator : No

But there are some issues with playusb.c, which is the userland program rendering to the frame display as the original playusb handles jpeg data and uses a buffer of a given length similar to st2205_send_data, but libdpf doesn't implement write_screen function yet.

Found AX206 DPF
Got LCD dimensions: 128x128
Waiting for update events from FB device /dev/fb1 ..

I will try to rewrite to use dpf_screen_blit and calculate the rect dimensions based on the buffer length.
No idea of the performance penalty though on the dockstar.

ax206term Wrote:
-------------------------------------------------------
> I forked Andre's
> Samsung Frame Framebuffer driver.
> ax206fb.c is
> done and can be loaded as kernel module, and
> /sys/kernel/debug/ax206fb is created. A simple
> test with fbset
>
> No idea of the performance penalty though on the
> dockstar.

The initial patches: patch against playusb and patch for ax206fb. Tested with both 128x128 and 320x240 frames.
Test suite consists of

cat rb.raw > /dev/fb1 #display image
cat /dev/zero > /dev/fb1 #blank screen
cat /dev/random > /dev/fb1 #display random bits

rb.raw is a 128x128 or 320x240 RGB888 image file prepared with ffmpeg"

ffmpeg -i rainbow.jpg -f rawvideo -vcodec rawvideo -pix_fmt rgb24 -s 128x128 rb.raw

I assume the framebuffer is internally using RGB888. playusb converts RGB888 to RGB565 to render to frame. fbset -i is used to check framebuffer video mode. You may need to set depth 24 and rgba flags of fbset.

Performance testing is needed on dockstar and code could be further simplified if RGB565 is also used on framebuffer then it is a byte-copy. mplayer doesn't like the framebuffer though but I can't figure out why yet:

VO: [fbdev2] 320x240 => 320x240 BGRA 
[fbdev2] visual: 3 not yet supported
FATAL: Cannot initialize video driver.
Too many buffered pts

ax206fb needs a kernel source tree to build. I will continue to work on this when time permits

ax206term Wrote:
-------------------------------------------------------
> ax206fb needs a kernel source tree to build. I
> will continue to work on this when time permits

 mount -t debugfs none /sys/kernel/debug

is needed for ax206fb before insmod. The module creates /sys/kernel/debug/ax206fb

I removed the unnecessary file I/O from playusb and fbgrab and here's a simple benchmark on my goflex net for ax206fb/playusb to display a 320x240 RGB888 image:

time cat rb2.raw > /dev/fb0
real	0m0.010s
user	0m0.000s
sys	0m0.000s
time cat /dev/zero > /dev/fb0
cat: write error: No space left on device
real	0m0.013s
user	0m0.000s
sys	0m0.000s

ax206term Wrote:
-------------------------------------------------------
> I removed the unnecessary file I/O from playusb
> and fbgrab
The updated patch for playusb without file io to speed things up

Hello everyone and thanks for the help. My problem is with DX frames, I can not do hack or Windows or Linux, I try but nothing. I put my log

[ 1656.455350] Initializing USB Mass Storage driver...
[ 1656.455531] scsi4 : usb-storage 4-1:1.0
[ 1656.455836] usbcore: registered new interface driver usb-storage
[ 1656.455838] USB Mass Storage support registered.
[ 1657.459117] scsi 4:0:0:0: CD-ROM            buildwin  Photo Frame     1.01 PQ: 0 ANSI: 2
[ 1657.466114] sr1: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
[ 1657.466268] sr 4:0:0:0: Attached scsi CD-ROM sr1
[ 1657.467113] sr 4:0:0:0: Attached scsi generic sg3 type 5
root@YAVDR:/home/gaby/dpf-ax/fw# sudo python knowndpfs.py /dev/sg3
root@YAVDR:/home/gaby/dpf-ax/fw# sudo python fulldump.py /dev/sg3
Opening generic SCSI device '/dev/sg3'
Manufacturer: Apple
Size        : 1 MB
Reading 100000 bytes...
Wrote full.bin
root@YAVDR:/home/gaby/dpf-ax/fw# sudo python hackit.py /dev/sg3
python: can't open file 'hackit.py': [Errno 2] No such file or directory
root@YAVDR:/home/gaby/dpf-ax/fw# sudo python identify.py /dev/sg3
^CTraceback (most recent call last):
  File "identify.py", line 346, in <module>
    data = f.read()
KeyboardInterrupt
root@YAVDR:/home/gaby/dpf-ax/fw# sudo python detect.py /dev/sg3
Opening generic SCSI device '/dev/sg3'
Manufacturer: Apple
Size        : 1 MB
root@YAVDR:/home/gaby/dpf-ax/fw#

@gabychan

sudo python identify.py  full.bin

dxfr Wrote:
-------------------------------------------------------
> @gabychan
>
>

> sudo python identify.py  full.bin
>

Thanks

root@YAVDR:/home/gaby/dpf-ax/fw# sudo python identify.py  full.bin
Looking for buildwin firmware....: Found (320x240 px).
Looking for known version info...: None.
Looking for Openwin..............: Found.
Looking for LcdIniTbl............: Found.
Looking for known signatures.....: None.

Sorry, no matching dpf found.

Hi gabychan,

please upload your full.bin. I willl have a look.

superelchi

superelchi Wrote:
-------------------------------------------------------
> Hi gabychan,
>
> please upload your full.bin. I willl have a look.
>
> superelchi

Thanks superelchi my full.bin here

gabychan Wrote:
>
> Thanks superelchi my full.bin
> [url=http://www.fileserve.com/file/HV9MV5x/full.bi
> n]here[/url]

Can not access your upload.
Error: "FileServe can only be used to download and retrieve files that you have uploaded personally.".

superelchi

Sorry

My_dump

Thanks I hope your help, sorry for the inconvenience

@gabychan

Bad news: this one is not supported at the moment. Its the DealExtrem # 21334, right? I also have on one these. I'm working on it - but its a tricky beast...

superelchi

superelchi Wrote:
-------------------------------------------------------
> @gabychan
>
> Bad news: this one is not supported at the moment.
> Its the DealExtrem # 21334, right? I also have on
> one these. I'm working on it - but its a tricky
> beast...
>
> superelchi


Thank you very much anyway, I have 3 frames waiting for their progress and impatient friends.

regards

I did a patch against MPlayer 2012-05-05 for st2205u frames using libst2205. I don't have any such frames so it's just a "./configure; make" testing. This started from version v1.4.1 from here

The intent of the patch is to understand how MPlayer was patched to output to st2205u devices and duplicate the feature over to ax206 frames using libdpf. The earlier work for st2205term v0.11 uses similar logic.

The RGB565 version of ax206fb/playusb proved to be much faster but I still cannot get mplayer to display anything on the framebuffer hence the move to patch mplayer for libdpf.

The first version of mplayer for ax206 with libdpf has dismal frame rates even on a PC and wrong color.

static int draw_slice(uint8_t *src[], int stride[], int w, int h, int x, int y)
{
	char *imagebuff;
	uint8_t *in = src[0];
	uint8_t *dest = dpf_imagebuff + (dpf_h->width * y + x) * 2;
	int next = dpf_h->width * 2;
	int i,j;

	//make sure we won't cross the boundaries of dest
	if (x>319) return 0;
	if (y>239) return 0;
	if (w+x>dpf_h->width) w=dpf_h->width-x;
	if (h+x>dpf_h->height) h=dpf_h->height-x;

	for (i = 0; i < h; i++) {
		//manually do a memcpy because the bytes
		//should be flipped first :X
		for (j=0; j<w; j++) {
		    dest[j*2]=(unsigned char)(RGB565_0(in[j*3+2],in[j*3+1],in[j*3]));
		    dest[j*2+1]=(unsigned char)(RGB565_1(in[j*3+2],in[j*3+1],in[j*3]));
		}
		dest += next;
		in += stride[0];
	}
	return 0;
}

changes to configure, Makefile, video_out.c were similar to my earlier patch for st2205u. I used these parameters for testing:

./mplayer -vo dpf -vf scale=320:240 -ao sdl -cache 8192 -framedrop test.mkv

I must have messed up something obvious with the colors again. Will look at it again when my mind is fresh. I'm open to suggestions to improve performance.

This code gave the correct colors for mplayer-ax206:

static int query_format(uint32_t format)
{
  if (dpf_preinit(0)) return 0;
  switch(format) {
  case IMGFMT_BGR16:
    return VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW | VFCAP_HWSCALE_UP | VFCAP_HWSCALE_DOWN | VFCAP_ACCEPT_STRIDE;
    return 0;
  }
  return 0;
}

static int draw_slice(uint8_t *src[], int stride[], int w, int h, int x, int y)
{
	char *imagebuff;
	uint8_t *in = src[0];
	uint8_t *dest = dpf_imagebuff + (dpf_h->width * y + x) * 2;
	int next = dpf_h->width * 2;
	int i,j;

	//make sure we won't cross the boundaries of dest
	if (x>319) return 0;
	if (y>239) return 0;
	if (w+x>dpf_h->width) w=dpf_h->width-x;
	if (h+x>dpf_h->height) h=dpf_h->height-x;

	for (i = 0; i < h; i++) {
		//manually do a memcpy because the bytes
		//should be flipped first :X
		for (j=0; j<w; j++) {
		    dest[j*2]=in[j*2+1];
		    dest[j*2+1]=in[j*2+1];
		}
		dest += next;
		in += stride[0];
	}
	return 0;
}

The patch against MPlayer 2012-05-05 to support both st2205u and ax206 frames, with libst2205 and libdpf respectively.

picframe wiki has been updated with ax206 information gleaned from this thread, openschemes, hackfin's site and dpf-ax sourceforge:

1. Programs' List.
2. Hacking log of a supported device.
3. Reverse Engineering notes.
4. Bootloader mode.

@superelchi:

For dx21334, is this sequence correct for lcdinit?

X14a1:	mov	_p3dir,#0x0	; 14a1   75 ec 00   ul.
	anl	_p1dir,#0xe8	; 14a4   53 ea e8   Sjh
	anl	_p2dir,#0xfd	; 14a7   53 eb fd   Sk}
	orl	_wdtcon,#0x20	; 14aa   43 bb 20   C; 
	clr	_LCD_CS		; 14ad   c2 a1      B!
	clr	_LCD_RST	; 14af   c2 90      B.
	mov	a,#0x96		; 14b1   74 96      t.
	lcall	X154c		; 14b3   12 15 4c   ..L
	setb	_LCD_RST	; 14b6   d2 90      R.
	mov	a,#0x96		; 14b8   74 96      t.
	lcall	X154c		; 14ba   12 15 4c   ..L
	mov	r7,#0x0		; 14bd   7f 00      ..
	mov	a,#0x2f		; 14bf   74 2f      t/
	mov	dptr,#X16a6	; 14c1   90 16 a6   ..&
	lcall	tramp_jsr	; 14c4   12 19 38   ..8
	ret			; 14c7   22         "

Is the challenging part the lcall to tramp_jsr?

Can we fold the code from 16a6 over but make adjustment to the addresses to fit into one module.

X16a6:	movx	a,@r0		; 16a6   e2         b
	mov	r4,a		; 16a7   fc         |
	clr	a		; 16a8   e4         d
	xch	a,r3		; 16a9   cb         K
	jz	X16b9		; 16aa   60 0d      `.
X16ac:	xch	a,r3		; 16ac   cb         K
	add	a,r3		; 16ad   2b         +
	xch	a,r3		; 16ae   cb         K
	mov	b,r6		; 16af   8e f0      .p
	mul	ab		; 16b1   a4         $
	add	a,r4		; 16b2   2c         ,
	mov	r4,a		; 16b3   fc         |
	clr	a		; 16b4   e4         d
	addc	a,b		; 16b5   35 f0      5p
	jnz	X16ac		; 16b7   70 f3      ps
X16b9:	mov	a,r3		; 16b9   eb         k
	mov	b,r5		; 16ba   8d f0      .p
	mul	ab		; 16bc   a4         $
	xch	a,r4		; 16bd   cc         L
	mov	b,r2		; 16be   8a f0      .p
	div	ab		; 16c0   84         .
	mov	r3,b		; 16c1   ab f0      +p
	add	a,r4		; 16c3   2c         ,
	movx	@r0,a		; 16c4   f2         r
	dec	r0		; 16c5   18         .
	djnz	r1,X16a6	; 16c6   d9 de      Y^
	ret			; 16c8   22         "

Or am I missing the point completely?

Hi ax206geek,

that part is not the problem. The sequence

	mov	a,#0x2f		; 14bf   74 2f      t/
	mov	dptr,#X16a6	; 14c1   90 16 a6   ..&
	lcall	tramp_jsr	; 14c4   12 19 38   ..8

calls offset 0x16a6 in module 48, which is the usual dump-LcdIniTbl-to-display routine. Thats what _lcd_custom_init in lcdinit.s does.
Problem seem to be a special initialisation of contrast and backlight (there is one additional LcdBackLightTbl). Displays backlight does stay off after our "standard" init. Toying a little with the backlight / contrast init and changing the backlight value blindly in dev-modes menu gave me some short blinks of the backlight with seemingly readable text. Will have a closer look, as soon as I'm finished with the next version of the firmware (bigger font, better menu, selectable startup splashscreen, etc.)

superelchi

superelchi Wrote:
-------------------------------------------------------
> Hi ax206geek,
>
> that part is not the problem. The sequence
>

> 	mov	a,#0x2f		; 14bf   74 2f      t/
> 	mov	dptr,#X16a6	; 14c1   90 16 a6   ..&
> 	lcall	tramp_jsr	; 14c4   12 19 38   ..8
>

> calls offset 0x16a6 in module 48, which is the
> usual dump-LcdIniTbl-to-display routine. Thats
> what _lcd_custom_init in lcdinit.s does.
> Problem seem to be a special initialisation of
> contrast and backlight (there is one additional
> LcdBackLightTbl). Displays backlight does stay off
> after our "standard" init. Toying a little with
> the backlight / contrast init and changing the
> backlight value blindly in dev-modes menu gave me
> some short blinks of the backlight with seemingly
> readable text. Will have a closer look, as soon as
> I'm finished with the next version of the firmware
> (bigger font, better menu, selectable startup
> splashscreen, etc.)
>
> superelchi


thanks

This means that we will soon have a version compatible with DX21334?

gabychan Wrote:
-------------------------------------------------------
>
> thanks
>
> This means that we will soon have a version
> compatible with DX21334?

I hope so - but its a tricky beast. So: no promises. ;-)

superelchi



Edited 1 time(s). Last edit at 05/09/2012 11:00AM by superelchi.

superelchi Wrote:
-------------------------------------------------------

> I hope so - but its a tricky beast. So: no
> promises. ;-)
>
> superelchi


Thank you very much again from Barcelona.

regards