Modding Libra 2

[undecimo]

Photo attached.

Another random observation - when connected via USB, the Libra 2 identifies itself as product 0x4234 running Nickel and 0xdead running KOReader. I assume unknown devices are 0xdead to KOReader and the Libra 2 ID can be added to a mapping table somewhere.

[NiLuJe]

@undecimo: Ah, that looks okay, thanks .

Does this behave in KOReader? (e.g., this latest fbdepth binary, and *NOT* disabling the x invert?).

As for the USB ids, that's to be expected, given that the USBMS tool hasn't been updated yet. It'll automagically behave once everything is merged .

[undecimo]

Hmm, it looks like touch_mirrored_x = false is still needed with the most recent fbdepth. I double checked the timestamp of the binary. The file size is exactly the same as the fbdepth I tested last night, but I'm sure I haven't mixed them up.

@7hir7een, can you confirm?

[xor_]

Originally Posted by NiLuJe

If you're willing to dig into it over shell (i.e., ssh/telnet), I have a test script that'll spit out all the gory details I need that I can send you?

If there's still something you need, i have ssh running on the libra 2.

[xor_]

see new post.

[NiLuJe]

Okay then, that possibly makes sense...

Just to double check, could you run the finger_trace tool, and see if it actually draws stuff in the right place (say, a short swipe in the top left corner).
Keep in mind that it'll fight to the death with whatever's attempting to redraw stuff below it ;p. (Hit Ctrl+C to quit).

Ideally, it would be amazing if someone could test this in all four rotations:

./fbdepth -R UR
./fbdepth -R CW
./fbdepth -R UD
./fbdepth -R CCW

But admittedly, just UR would be a good start .

I also wouldn't mind having a look at the full terminal output of these runs .

----

On another matter completely, if someone could poke in /sys/class/backlight to see where the frontlight & LED controls are hidden, that would be neat (It *looks* like it's the exact same thing as on the Libra, but I don't recall if anyone actually confirmed that ^^).

[undecimo]

I assume @xor_ is correct and the latest fbdepth solves the x-axis flip. I may have forgotten to roll back other edits in my KOReader install. I'll do a fresh install tonight and run the additional tests.

Anecdotally I can say that the Libra H2O frontlight code seems to work very well with the Libra 2. Manual controls are perfect and auto warmth (which I'm running in expert mode) behaves as configured.

[xor_]

Originally Posted by NiLuJe

Just to double check, could you run the finger_trace tool, and see if it actually draws stuff in the right place (say, a short swipe in the top left corner).
Keep in mind that it'll fight to the death with whatever's attempting to redraw stuff below it ;p. (Hit Ctrl+C to quit).

Looks all plausible to me.

Ideally, it would be amazing if someone could test this in all four rotations:

fbdepth -R UR
fbdepth -R CW
fbdepth -R UD
fbdepth -R CCW

See attachment.

On another matter completely, if someone could poke in /sys/class/backlight to see where the frontlight & LED controls are hidden, that would be neat

ls -lA /sys/class/backlight/

lrwxrwxrwx    1 admin    root             0 Oct 24 00:39 lm3630a_led -> ../../devices/platform/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0036/backlight/lm3630a_led
lrwxrwxrwx    1 admin    root             0 Oct 24 00:39 lm3630a_leda -> ../../devices/platform/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0036/backlight/lm3630a_leda
lrwxrwxrwx    1 admin    root             0 Oct 24 00:39 lm3630a_ledb -> ../../devices/platform/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0036/backlight/lm3630a_ledb
lrwxrwxrwx    1 admin    root             0 Oct 24 00:39 mxc_msp430.0 -> ../../devices/platform/ntx_bl/backlight/mxc_msp430.0

[NiLuJe]

Oh, I, err, realize I might have worded this a bit poorly .

The interesting bit would actually have been running ./finger_trace *between* every fbdepth invocation, that wasn't clear, my bad ;p.

[NiLuJe]

And I possibly misread half of everything last night, because sleep is good for your brain, do it!

So, another key point I might have forgotten to mention:

I'm assuming the device is physically set up right-handed (i.e., buttons on the right).

So, if I revert last night's fever dream, *this* finger_trace binary should behave .

[xor_]

Originally Posted by NiLuJe

So, another key point I might have forgotten to mention:

I'm assuming the device is physically set up right-handed (i.e., buttons on the right).

So, if I revert last night's fever dream, *this* finger_trace binary should behave .

Ok, next try. It's always reversed.

[xor_]

Okay, sorry about the confusion last night.

Today I could reproduce, using this latest fbdepth, that with mirrored = true, the tap zones are rerversed.

With mirrored = false, everything pretty much works as expected.

I did see occasional crashes after fiddling with some of the menus. Will look into that by actually using the reader for a bit.

[NiLuJe]

Okay, so the finger_trace binary from last night https://www.mobileread.com/forums/sh...9&postcount=21 *should* behave properly, right?

[xor_]

Originally Posted by NiLuJe

Okay, so the finger_trace binary from last night https://www.mobileread.com/forums/sh...9&postcount=21 *should* behave properly, right?

I'm afraid it's not so easy. I get a lot of errors like the following, and afterwards weirdness happens.

libevdev error in sanitize_event: BUG: Device "Elan Touchscreen" received a double tracking ID 247 in slot 0.

As far as I an tell, with fbdepth -R UR, the movement tracking is always correct. With UD, it's always reversed.

With CW and CCW, it's mostly screen corruption and no easily decipherable correlation to my finger movements.

[NiLuJe]

The errors are perfectly "normal": it's just the Elan driver being the worst, but it's harmless in practice.

I'm going to need an idea of *where* you were actually touching the screen to make sense of what's happening, though ;o).