Nonvnc and Opensource to Use DX(G) as a PC Display

[thatworkshop]

Bug report: Once mylcd is run, even if I kill mylcd, screensaver will not get activated (even by power button!). I see lipc is being used. So after using mylcd, I alway have to manually do:

lipc-set-prop -i com.lab126.powerd preventScreenSaver 0

so that my Kindle can go to sleep.

[thatworkshop]

Originally Posted by nahte

https://github.com/nahtethan/dxg-display

- Still Building.
- Contributor and suggestion are welcome.
- Displaylink's Linux udlfb module is used in PC side, so I think some senior here already knew it is required to write a usb gadget driver for dxg, right?

Here to help to get this going...

[knc1]

I am not sure if collaborate translates.
Hmm...
合作
Includes "conspire" so not very exact.

[nahte]

Originally Posted by nahte

https://github.com/nahtethan/dxg-display

- Still Building.
- Contributor and suggestion are welcome.
- Displaylink's Linux udlfb module is used in PC side, so I think some senior here already knew it is required to write a usb gadget driver for dxg, right?

My gadget code is based on linux-2.6.22-lab126, which is kindle dxg's kernel. The directory path here is kept same as to linux-2.6.22-lab126, which can be downloaded from https://kindle.s3.amazonaws.com/Kind...5370010.tar.gz

The android gadget driver is pretty cool for usb, so the first step is porting android gadget driver.

[thatworkshop]

Originally Posted by nahte

My gadget code is based on linux-2.6.22-lab126, which is kindle dxg's kernel. The directory path here is kept same as to linux-2.6.22-lab126, which can be downloaded from https://kindle.s3.amazonaws.com/Kind...5370010.tar.gz

The android gadget driver is pretty cool for usb, so the first step is porting android gadget driver.

Happy 10th post!
I told you GitHub is awesome and GitHub Desktop is super easy.

Let's compile and include a binary too.

Speaking of compiling, "Not clear how to compile a Linux module like udlfb?" you are not sure how to compile the so-called mylcd or a linux module?

[nahte]

I guess everybody just want to take a try of the binaries, go github to download and try!

https://github.com/nahtethan/dxg-display

[knc1]

I happened to notice this snippet:

/*
 * DisplayLink HW has separate 16bpp and 8bpp framebuffers.
 * In 24bpp modes, the low 323 RGB bits go in the 8bpp framebuffer
 */

Since the e-ink devices are grayscale, you would probably get a much nicer display if you dithered 888 to 323 encoding rather than a simple truncate.

For inspiration:
Geekmaster posted some very fast dither code here (un-maintained).
And KOReader uses dither code.

Q?:
Does the DXG even have 8bpp frame buffer?
Or is it one of the Kindle 4bpp frame buffers, with tricky packing to 1 byte per pixel?

[NiLuJe]

IIRC, FW 2.x means 4bpp, yeah.

[thatworkshop]

@nahte: Have you changed the way this mylcd works as compared to previous mylcd (trial)?

Yes, only 4bpp on DX(G).

Indeed, using geekmaster's video player stuff in mylcd would be fun.

Thanks @nahte. I preferred the way previous (trial) version worked a bit more, as now usbnetworking is disabled while running mylcd and g_android.ko is loaded.

In Kindle, module arcotg_udc depends on g_ether, we shouldn't be worried about it?

[knc1]

Originally Posted by NiLuJe

IIRC, FW 2.x means 4bpp, yeah.

IIRC Geekmaster had his dither routines conditionalized to handle all of the strange bit packings used by the various Kindle models.

[thatworkshop]

Originally Posted by nahte

I guess everybody just want to take a try of the binaries, go github to download and try!

https://github.com/nahtethan/dxg-display

I think the way previous mylcd worked was kind of better, because the usbnet connection didn't need to disconnect for g_android to be loaded. It's a neater solution for some people like me who always use their devices in USBnet mode.

[nahte]

Originally Posted by knc1

Geekmaster posted some very fast dither code here (un-maintained).

Q?:
Does the DXG even have 8bpp frame buffer?
Or is it one of the Kindle 4bpp frame buffers, with tricky packing to 1 byte per pixel?

Where is link of Geekmaster's dither code? Actually I use some algorithm to transfer displaylink's 16bpp data to dxg's 4bpp fb, And I only use 2 grayscale levels of the dxg 16 levels: pure white and pure black. That will give dxg fantastic reading experience when display text material. It will be cool to modify displaylink's code to transfer only 4bpp or less data, which will speed up the transfer.

BTW, did you guys try my binaries? It work well or not?

[thatworkshop]

Originally Posted by nahte

Where is link of Geekmaster's dither code? Actually I use some algorithm to transfer displaylink's 16bpp data to dxg's 4bpp fb, And I only use 2 grayscale levels of the dxg 16 levels: pure white and pure black. That will give dxg fantastic reading experience when display text material. It will be cool to modify displaylink's code to transfer only 4bpp or less data, which will speed up the transfer.

BTW, did you guys try my binaries? It work well or not?

Here for a starters:
https://www.mobileread.com/forums/sho...d.php?t=175632
https://www.mobileread.com/forums/sho...d.php?t=177455

I tried it, as I mentioned earlier, there is a change in mechanism between this and the previous trial version?

[nahte]

Originally Posted by idoit

I tried it, as I mentioned earlier, there is a change in mechanism between this and the previous trial version?

So the binary works, right? This mylcd 2.0 is much better:
- the mechanism provides copy and extend display mode
- speed will be faster cos displaylink is driver level
- this support linux, everybody like linux, right?

I have a question too, how to trigger dxg in kernel/driver to fresh the screen when framebuffer's data has change?

[thatworkshop]

Originally Posted by nahte

So the binary works, right? This mylcd 2.0 is much better:
- the mechanism provides copy and extend display mode
- speed will be faster cos displaylink is driver level
- this support linux, everybody like linux, right?

I have a question too, how to trigger dxg in kernel/driver to fresh the screen when framebuffer's data has change?

It doesn't work on my DXG. In fact, it makes it instantly reboot!

I'd say let's go back to how v1 was working (without rmmod g_ether and ...) and use dithermation to speed up instead. ?