ax206geek Wrote: ------------------------------------------------------- > @C4Vette: Your dx21334 firmware seems to differ > from other dx21334 firmware after running a diff > with gabychan's firmware. Right. Both are DX #21334 but have different firmware. AND: tried to flash C4Vette's dump to my 21334 (= same firmware as gabychan's). Not working. :-( superelchiby superelchi - Displays
Hi, thanks for the dx27893. I have one of these myself but forgot to add it. :-o Will be available as new model "dx27893" in the next svn commit. Just finished adding a new feature for those, who want to connect more than one display at the same time: USB iSerial Number adjustable in dpfs menu. Now its possible to identify each dpf by a unique serial number, e.g. in a udev rule.by superelchi - Displays
FYI: new dpf-ax version 0.3 in svn. Its now possible to build 2 different firmware versions: - 'Developer' version: firmware with same features and look as pre-0.3 versions ("Blue Screen of Hack"). - 'Display' version: firmware for use as a status display (lcd4linux, vdr, etc.) with bigger font, new menu and selectable splashscreen. superelchiby superelchi - Displays
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. ;-) superelchiby superelchi - Displays
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 (therby superelchi - Displays
@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... superelchiby superelchi - Displays
gabychan Wrote: > > Thanks superelchi my full.bin > here Can not access your upload. Error: "FileServe can only be used to download and retrieve files that you have uploaded personally.". superelchiby superelchi - Displays
Hi gabychan, please upload your full.bin. I willl have a look. superelchiby superelchi - Displays
@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. superelchiby superelchi - Displays
petergunn Wrote: ------------------------------------------------------- > My ax206 frame (looks like a pearl) doesnt seem to > be supported... > > Any suggestions? I'm using dpfhack-0.1alpha.tgz > and current svn trunk of dpf-ax > > -PG Use identify.py from the current svn branch. Hackit-py / detect.py are from older releases. You need a full fw-dump forby superelchi - Displays
Hi ax206term, had a short look at your code. Some suggestions: Line 60: static unsigned char colormap[8]={0,0,0}; should be static unsigned int colormap[8]; Line 278: unsigned char rgb,rgb_fg=colormap,rgb_bg=colormap; int m,n; for (m=0;m<f->h;m++) { //Each font character if a rectangular array of pixels. //m is the y-coordinate within the pixel arby superelchi - Displays
hackfin Wrote: ------------------------------------------------------- > sure, the old procotol will stay, the dpflib > recognizes different types. The reason actually > is, that I've been noodling kind on a remote > display running on a FPGA with attached USB FIFO > with a much simpler protocol (stripped down > netpp). And the 'hacked' SCSI protocol is whby superelchi - Displays
hackfin Wrote: ------------------------------------------------------- > > As another, somewhat more efficient protocol is in > the pipeline (experimental), it will break > compatibility if you roll your own blitting code. > I'd recommend to look at the lcd4linux patches to > see how the libdpf is integrated. It's rather > easy, if your code is somewhat objby superelchi - Displays
>Is /dev/bus/usb/004/021 the right device for the AX206 picframe? No. Its not. Libdpf uses "usb0" only as a keyword. Usb0 = first connected dpf, usb1 = second one, etc. It will search for the correct device name/number by itself. There is no device named /dev/usb0 (unless you write your own udev rule.) superelchiby superelchi - Displays
Hi ax206term, if you need some hints how to code the backbuffer/transmission to ax206, have a look at my VDR graphlcd driver. This driver is a little complex, because it supports up to four displays, hotplugging, auto-rotation, etc. But the basic approach should be easy to grab. Note that I did not use libdpf for this. Did some "creative copy&paste" from libdpf sources. Sorry hby superelchi - Displays
FYI: new version (0.205) in svn. Firmware now works with dpflib 0.1alpha. No more segfaults. superelchiby superelchi - Displays
Hi rotidude, commited your patch to svn (renamed it to delightdigi_black). Thanks! superelchiby superelchi - Displays
>Should I start modifying identify.py to dump module 51 with the aim of running d52 at 0x14ca? No, all Lcd*Tbl are just - tables. Nothing to disassemble here. Dpf-ax fw does not use any of these tables besides LcdIniTbl at the moment. Maybe I will integrate the contrast/backlight table in the future. Do not ask when. :-) Is contrast/brightness much better with the original firmware or is itby superelchi - Displays
Hi rotidude, yes, for your kind of displays thats the way to do it. Next step is to disassemble openwin_tmp.bin. Get yourself d52 (8052 Disassembler) and do: d52 -p -b -n openwin_tmp.bin x1280 You will get openwin_tmp.d52. Do some cleanup (identify the blit-coordinates, etc.). Thats the one to go into lcdblit.s. Following file may help by identifying some often used vars. Create a fileby superelchi - Displays
Sight. Next one. superelchiby superelchi - Displays
Okay. What about this? superelchiby superelchi - Displays
@buspirate Please try this for your 128x144 dpf. Renamed it and fixed bug (screwed hight and width). :-o superelchiby superelchi - Displays
@buspirate Could you please upload the original fw for your 128x144 dpf again? Just to make sure I have the correct one... BTW: is the original fw portrait (128 hor, 144 vert) or landscape (144 hor, 128 vert)? @neon There is no easy "follow-these-steps" way to add a new dpf. I rearranged the sources a little bit and added some helpers (like identify.py) to make it easier. But - yoby superelchi - Displays
@buspirate Please try attached firmware. Not sure if I got it right - is it really a 128 x 144 pixel dpf? superelchiby superelchi - Displays
prezes_kk Wrote: ------------------------------------------------------- > may thx its working ;] Fine. So I will add it to the list of supported models. BTW: do you have a link to a site where this model is available? > how to create a udev rule ? There are many tutorials all over the web how to work with udev. But if you plan to use the display only with existing drivers and/or liby superelchi - Displays
prezes_kk Wrote: ------------------------------------------------------- > after flash fw_agk_violet.bin firmware screen > position is correct and colors is ok > but device usb0 is not created and image is > broken Screen fixed. The term "usb0" ist just used by the dpf-ax lib as a selector for the hacked-fw. If you want a device named /dev/usb0 you have to create yourby superelchi - Displays
Hi buspirate, Good news: commited a new version of identify.py to svn that will work with your dump. Bad news: your fw does not use the "standard" way of initializing the lcd by a table. Everything seems to be done in LcdInit . This is currently not supported by the svn version of dpf-ax. Working on it. Will be ready in a couple of days. superelchiby superelchi - Displays
@prezes_kk I added a new model based on your dump. Please try attached firmware. Am I correct - its a 128 x 128 lcd? @buspirate Seems to be a problem of identify.py. Worked with all dumps I could grab. Yours seems to be special. :-) Could you upload a dump? superelchiby superelchi - Displays
@prezes_kk What about the focal fw? Please post a dump of the original fw and I will see what I can do. :) superelchiby superelchi - Displays
Hi buspirate, you could try the focal firmware from svn or precompiled here. We have successfully flashed some greatfoto DPFs with this firmware. Also I'm currently working on an update to dpf-ax with support for some new models and a new detection program. Will be ready for commit in a few days. One new model - linkdelight - is availabe as a preview here. superelchiby superelchi - Displays