luajit: frontend/a:50: Could not find hardware abstraction for this platform. a:27: Not able to load dynamic library: libSDL2-2.0.so.0 It's KOReader!įfi.load (warning): libSDL2.so: cannot open shared object file: No such file or directoryįfi.load (warning): libSDL2-2.0.so: cannot open shared object file: No such file or directoryįfi.load (warning): libSDL2-2.0.so.0: cannot open shared object file: No such file or directory If you are trying to run the emulator, please ensure SDL is installed. return require("device/newport/device")Įrror( "Could not find hardware abstraction for this platform. Return require( "device/cervantes/device ") Return require( "device/sony-prstux/device ") Return require( "device/remarkable/device ") Return require( "device/pocketbook/device ") Local kindle_sn = io.open( "/proc/usid ", "r ") Return require( "device/android/device ") (In our context, I'm hoping you can/should pretty much forget about it, unless it turns out the hardware does stupid things if you queue multiple updates before completion of previous ones, in which case you'll have to handle the blocking in userland). The GET_UPDATE_STATUS ioctl is NOT a 1:1 match for the mxcfb wait_for_completion stuff: while the mxcfb EPDC will block for you, in-kernel, this just returns 1 if there's currently an update being processed, and 0 otherwise (it's basically a getter for an internal global flag in the driver). Not quite sure what's up with the split A2 (IN/OUT), I suspect they're used for some sort of automagic A2->!A2 chaining, which we probably don't care about. No idea what sel & fb_id are supposed to be used for (well, fb_id more or less speaks for itself D), leaving 'em both at 0 seems cool (in fact, quite a few Disp_eink functions seem to take a sel argument and then never do anything with it, so, eh.). Mode is actually a bitmask (c.f., Disp_eink_update), I suspect the "LOCAL" (EDIT: and/or "RECTANGLE") stuff more or less matches freescale's PARTIAL stuff (i.e., regional, non-flashing updates). (The strace approach is slightly more work upfront, but much less unwiedly in practice once you're rg Disp_eink_update ──(Sun, Apr 12)─┘ġ864: ret = Disp_eink_update(ubuffer, ubuffer, ubuffer, coordinate) ĭrivers/video/sun5i/disp/de_bsp/bsp_display.hģ21:extern _s32 Disp_eink_update(_u32 sel, _u32 fb_id, _u32 mode, _u32 coordinate) ĭrivers/video/sun5i/disp/de_bsp/de/disp_eink.hġ94:_s32 Disp_eink_update(_u32 sel, _u32 fb_id, _u32 mode, _u32 coordinate) ĭrivers/video/sun5i/disp/de_bsp/de/disp_eink.cġ781: Disp_eink_update(0,0, EINK_GC16_MODE, coordinate) ġ783: Disp_eink_update(0,0, EINK_SHORT_GC16_LOCAL_MODE, coordinate) Ģ544:_s32 Disp_eink_update(_u32 sel, _u32 fb_id, _u32 mode, _u32 coordinate) The other approach is an interposer via an LD_PRELOAD hack (c.f., Kobo's really old one, and libremarkable's for current i.MX6-ish boards). My usual approach is to patch strace to decode those ioctls and see what happens in the stock software (c.f., the strace section in my build script and the matching Kobo mxcfb patch (which is possibly slightly less convoluted to grok that the Kindle ones)). Some of those waveform mode constants look funky as hell, it'll probably take a trip to the code to figure out why they're so convoluted. The layout of the structure's reference to pass to that is still confusing, but at least your first example seems to know what to do with most of it. That's a few less magic numbers in the way, which is good. AW's "display engine" (or whatever it's actually called) here, instead of my good friend the PxP on Freescale HW ).Īs another example, I seem to recall the Sipix drivers being much closer in spirit to the Freescale API, That's a good start. Not the same video/image block (i.e., what passes as a "graphics card" in these things).
0 Comments
Leave a Reply. |