Plato: A document reader for PDF, ePUB, DjVu, etc. - Page 16

baskerville · 10-24-2018, 06:35 AM

While planning the implementation of the landscape mode, it occurred to me that it would be much easier to just handle framebuffer rotation as it only requires a transformation of the touch input coordinates instead of having to implement these transformations in a myriad of intermediate functions.

I'll expose my understanding of the situation on the Glo HD and then try to generalize:

When the framebuffer rotation is 270° in the clockwise direction, the device is in portrait mode with the logo at the bottom.
The touch input coordinates are relative to the 0° rotation.
Therefore, the transformation that we need to apply to the touch coordinates (swap x and y and mirror x) is just a consequence of the 270° rotation.

Some devices (Aura HD, Aura H₂O and Aura H₂O Edition 2 according to KSM) require a different rotation to accomplish the same result. If we interpret the rotation as 90° clockwise, then the touch input transformation, should be to swap x and y, and mirror y. This isn't the case. One way of making sense of this is to consider that we're dealing with a 90° rotation in the counter clockwise direction.

Does this quirk have to do with a particular framebuffer depth, as the comments in FBInk seem to indicate?

There's also the Aura H₂O Edition 2 Version 1: the x axis isn't mirrored on this device. This means that we can't interpret the display coordinates as a rotation of the touch coordinates.

In any case, if you have one of the aforementioned devices, I would appreciate if you could provide an interpretation for the 0, …, 3 rotation numbers in regard to their meaning in an operational Linux framebuffer.

When I echo 0, …, 3 to /sys/class/graphics/fb0/rotate I can observe the changes in the output of fbset. In particular, xres_virtual * yres_virtual changes. Does that mean I have to call mremap when I switch from portrait to landscape and vice versa? Or maybe I'm doing things wrong and I should just pass fix_info.smem_len as second argument to mmap?

NiLuJe · 10-24-2018, 12:26 PM

From what I gather, it's generally a funky mess, and there was a point in time when it was even messier, with vinfo rotate basically bearing no actual relation to what the fb was expecting (... well, even less than now), and where forcing it to a specific value yielded massively weird results. I wasn't playing with fb at the time, so @frostschutz probably remembers more about this than I do

.

From my very small sample of *one* H2O: the touch panel never ever rotates, and *probably* matches the "native" boot rotation of the FB (which appears to be something like a reverse landscape, so, CCW?, despite reporting 0).

On current FW, at startup, Nickel puts the fb in 32bpp mode, and rotates it in portrait. That ends up being reported as a CW rotation (1), so, okay, why not.

Pickel, which is used to display the three dots progress bar, among other things, puts it back in 16bpp mode, in landscape (but the inverse of the boot landscape), which is reported as 2 (UD). AFAICT, that was the state Nickel kept in FW before the 32bpp switch.
(Fun fact: that's the reason why KFMon's initial welcome message is upside down: I'm applying the pickel rotation to a fb that's still in early boot rota).

TL;DR: vinfo rotation appears to be unfortunately barely useful on its own, because, when it works, it appears to be relative to the native rotation, which may not be Portrait. It's pretty much the same on Kindle, where it varies wildly between models.

EDIT: As for smem_len, it doesn't change between 16bpp and 32bpp, which is a bit weird, but saves me a remap. One possible explanation might be that there was probably supposed to be panning/flipping support in 16bpp (despite, again, that not being made apparent elsewhere

)?

(Or a weird shadow buffer optimization like there was on the old einkfb controller?)

Since I barely care about 16bpp anyway, I'm not overly concerned with the fact that I may be mapping double what I actually need. It's certainly still fb memory, so, nothing ever blows up, even with a full memset on it.

So far, trusting smem_len hasn't bit me on the ass on Kindle & NTX devices, but I know from KOReader that it's massively broken on PocketBook devices, for instance...

EDIT²: It shouldn't bear any relation to landscape/portrait, because it should always at least be equal to line_len * yres_virtual (* bufferN if offset > 0, which it never is), and that's usually been sane in my experience.

EDIT³: Fun fact: rotation is weird pretty much everywhere: my desktop's EFI framebuffer happily reports

Code:

[FBInk] Variable fb info: 1920x1080, 32bpp @ rotation: 0 (Upright, 0°)
[FBInk] Fixed fb info: ID is "simple", length of fb mem: 8847360 bytes & line length: 8192 bytes

so, 0/U for landscape

. (For those doing the smem_len maths at home, yeah, virt dims are 2048, except they're not reported as such, because everything is terrible).

Granted, that may or may not be a factor here:

Code:

zgrep ROTA /proc/config.gz                                                                                                                                                                                                           
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set

NiLuJe · 10-24-2018, 12:30 PM

This leads me to another point: I never tried really hard, because I was afraid this would potentially break basically everything else (since, in my case, I'm mostly expected to be running while Nickel is up, and as playing with pickel showed, it doesn't really like having the rug swept from under its feet when the fb mode changes

), but I've only had moderate success (read: none, rotation or yres/xres inversion was always fucked up) in switching to a fb mode/rotation of my choosing via fbset, so I'll be following your efforts with bated breath

.

NiLuJe · 10-24-2018, 01:49 PM

Okay, I think I'm done updating my first answer, so, to recap, in chronological order:

Boot: 16bpp, rota 0 (but for us, holding the device, it's a CCW landscape). Probably matches the touch panel, at least on my device.
Pickel: 16bpp, rota 2 (for us, CW landscape)
Nickel: 32bpp, rota 1 (for us, UR portait, yay!)

NOTE: I may be getting my CW/CCW mixed up. This shit breaks my brain ;D.

EDIT: Hey, progress re: my second answer.
After running pickel, I can get back to the Nickel mode & rota by doing:

Code:

fbset -geometry 1080 1440 1088 1536 32

(xres/yres/xres_virt/yres_virt/bpp, run fbset with no args to get the proper syntax of the current mode).

After which I'm in...

Code:

[FBInk] Variable fb info: 1440x1080, 32bpp @ rotation: 0 (Upright, 0°)

Then...

Code:

echo 1 > /sys/class/graphics/fb0/rotate

After which I'm in...

Code:

[FBInk] Variable fb info: 1080x1440, 32bpp @ rotation: 3 (Counter Clockwise, 270°)

(Yeah, WTH?!)

But, finally...

Code:

echo 3 > /sys/class/graphics/fb0/rotate

leads to the expected

Code:

[FBInk] Variable fb info: 1080x1440, 32bpp @ rotation: 1 (Clockwise, 90°)

And Nickel is happy again

.

EDIT²:
A single echo 3 >| /sys/class/graphics/fb0/rotate does the job

.

All of this should be reproducible in C with a single (hopefully) FBIOPUT_VSCREENINFO ioctl, and that rotation quirk will hopefully make more sense there without having to devise the rota to set via a shenanigan like 1^2 == 3 (which suspiciously matches target ^ current in my example...) ...

NiLuJe · 10-24-2018, 02:13 PM

What all this does the the mxcfb region the eink controller expects is left to the reader to figure out, because brain mushy now >_<".

Fire bad. Tree pretty.

baskerville · 10-24-2018, 02:31 PM

Thanks, that's insightful. Could you also try echoing 0 and 2?

NiLuJe · 10-24-2018, 05:13 PM

From nickel (1080x1440, 32bpp, rota 1 (CW), fb origin at the top-left corner):

0 -> 1440x1080, 2 (UD), fb origin at the top-right corner
1 -> 1080x1440, 3 (CCW), fb origin at the bottom-right corner
2 -> 1440x1080, 0 (UR), fb origin at the bottom-left corner
3 -> Back to Nickel state.

---

From pickel (1440x1080, 16bpp, rota 2 (UD), fb origin at the top-right corner)

0 -> Back to pickel state
1 -> 1080x1440, 3 (CCW), fb origin at the bottom-right corner
2 -> 1440x1080, 0 (UR), fb origin at the bottom-left corner [That's the status at boot]
3 -> 1080x1440, 1 (CW), fb origin at the top-left corner

---

So at least that's consistent, and the final rotation equals input ^ 2

NiLuJe · 10-24-2018, 05:18 PM

Because this came up very recently in a discussion w/ poire-z, there's another advantage to using the hardware rotation: it allows you to easily take appreciable shortcuts when blitting.

On an unrelated note, this was also one of my pet-peeves with 16bpp on Kobo: it makes no goddamn sense without hardware blitting, because RGB565 is a terrible pixel format for software blitting when nothing else ever uses it.

32bpp is at least better, but is still questionable on a device that only has a 16 color palette, which, hey, an 8bpp fb handles just right, just ask Amazon

. And it's addressable, which is a plus, because 4bpp fbs are annoying as hell to handle ;p.

NiLuJe · 10-24-2018, 09:43 PM

And because of course, something had to keep being mysterious:

When attempting to duplicate the boot rotation via pickel+sysfs, while I end up with what appears to be an identical modeset (i.e., 1440x1080, 16bpp @ rotation: 0 (Upright, 0°)), it turns out, not so much.

After implementing proper rotation for that "duplicated" modeset in FBInk, and updating KFMon to use that, my welcome message is still not positioned properly...
It's no longer upside down and RTL, but it's not positioned properly on the y axis (it's inverted: near the top instead of near the bottom).

-_-".

(And, AFAICT, no, it's not because pickel manages to change modeset between my init and my first message, because that behaves in yet another way...).

EDIT: Hmm. After running another set of experiments with *no* rotation tweaks at all, it *might* still be a race with pickel after all, that at least makes some kind of sense given the timing...

NiLuJe · 10-26-2018, 07:06 PM

Okay, a final comment on the smem_len thing:

Someone (@pazos) recently ported FBink to BQ/Cervantes devices (which are based on the same NTX hardware as Kobos), and reported weird softlocks after a screen clear over the stock reading app.

I was doing that with a simple smem_len memset.

Turns out, when it can (i.e., @ 16bpp), the Qt Embedded driver they (and possibly others) use uses memory from the offscreen buffer to do... stuff.
I'm too lazy to dig into this much (c.f., https://github.com/bq/cervantes-qt/b...kfb/einkfb.cpp, size/psize vs. mapsize), so I'll be switching that memset to line_len * yres (and not yres_virtual like I'd like, because apparently Qt starts monopolizing memory potentially earlier than that).

AFAICT, the mmap is perfectly fine, though

.

baskerville · 10-29-2018, 05:52 AM

Regarding the touch coordinates transformation, the mapping is the following for most devices:

Code:

0 → Identity
1 → Sxy My
2 → Mx My
3 → Sxy Mx

Where S means swap and M means mirror.

The mapping for the Aura H₂O Edition 2 Version 1 is:

Code:

0 → Mx
1 → Sxy
2 → My
3 → Sxy Mx My

The swapping pattern is identical and the mirroring pattern is shifted downward. Hence the only device specific information needed to compute the transformation given the rotation is the center of the mirroring pattern.

NiLuJe · 10-29-2018, 10:02 AM

Neat!

I'd be *very* curious to see what

Code:

ntx_hwconfig -v -s /dev/mmcblk0 DisplayPanel

returns on the H2O²r1 (and anywhere else, as a matter of fact

), I was hoping that'd provide a reliable info regarding the "native" (i.e., hopefully matching the touch panel) rotation...

FWIW, on my H2O:

Code:

DisplayPanel='6.8" Bottom EPD'

patrik · 10-29-2018, 10:20 AM

Aura HD, 4.8.11073

Code:

ntx_hwconfig_ap.c(1110):vserbose level 1 . 
NtxHwCfg_GetCfgFldStrVal:[WARNING]Config version too old !! Please update config file !!
[10] DisplayPanel='6.8" Bottom EPD'

NiLuJe · 10-29-2018, 10:22 AM

So far, so, good, that makes sense, thanks @patrik

.

CH23 · 11-02-2018, 03:48 AM

Clara HD, using the KSM build-in terminal:

Code:

DisplayPanel='6" Bottom EPD'

10-24-2018, 06:35 AM	#226
baskerville Evangelist Posts: 443 Karma: 305160 Join Date: Aug 2015 Device: Kobo Glo HD, Kobo Aura ONE	While planning the implementation of the landscape mode, it occurred to me that it would be much easier to just handle framebuffer rotation as it only requires a transformation of the touch input coordinates instead of having to implement these transformations in a myriad of intermediate functions. I'll expose my understanding of the situation on the Glo HD and then try to generalize: When the framebuffer rotation is 270° in the clockwise direction, the device is in portrait mode with the logo at the bottom. The touch input coordinates are relative to the 0° rotation. Therefore, the transformation that we need to apply to the touch coordinates (swap x and y and mirror x) is just a consequence of the 270° rotation. Some devices (Aura HD, Aura H₂O and Aura H₂O Edition 2 according to KSM) require a different rotation to accomplish the same result. If we interpret the rotation as 90° clockwise, then the touch input transformation, should be to swap x and y, and mirror y. This isn't the case. One way of making sense of this is to consider that we're dealing with a 90° rotation in the counter clockwise direction. Does this quirk have to do with a particular framebuffer depth, as the comments in FBInk seem to indicate? There's also the Aura H₂O Edition 2 Version 1: the x axis isn't mirrored on this device. This means that we can't interpret the display coordinates as a rotation of the touch coordinates. In any case, if you have one of the aforementioned devices, I would appreciate if you could provide an interpretation for the 0, …, 3 rotation numbers in regard to their meaning in an operational Linux framebuffer. When I echo 0, …, 3 to /sys/class/graphics/fb0/rotate I can observe the changes in the output of fbset. In particular, xres_virtual yres_virtual* changes. Does that mean I have to call mremap when I switch from portrait to landscape and vice versa? Or maybe I'm doing things wrong and I should just pass fix_info.smem_len as second argument to mmap?

10-24-2018, 12:26 PM	#227
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	From what I gather, it's generally a funky mess, and there was a point in time when it was even messier, with vinfo rotate basically bearing no actual relation to what the fb was expecting (... well, even less than now), and where forcing it to a specific value yielded massively weird results. I wasn't playing with fb at the time, so @frostschutz probably remembers more about this than I do . From my very small sample of one H2O: the touch panel never ever rotates, and probably matches the "native" boot rotation of the FB (which appears to be something like a reverse landscape, so, CCW?, despite reporting 0). On current FW, at startup, Nickel puts the fb in 32bpp mode, and rotates it in portrait. That ends up being reported as a CW rotation (1), so, okay, why not. Pickel, which is used to display the three dots progress bar, among other things, puts it back in 16bpp mode, in landscape (but the inverse of the boot landscape), which is reported as 2 (UD). AFAICT, that was the state Nickel kept in FW before the 32bpp switch. (Fun fact: that's the reason why KFMon's initial welcome message is upside down: I'm applying the pickel rotation to a fb that's still in early boot rota). TL;DR: vinfo rotation appears to be unfortunately barely useful on its own, because, when it works, it appears to be relative to the native rotation, which may not be Portrait. It's pretty much the same on Kindle, where it varies wildly between models. EDIT: As for smem_len, it doesn't change between 16bpp and 32bpp, which is a bit weird, but saves me a remap. One possible explanation might be that there was probably supposed to be panning/flipping support in 16bpp (despite, again, that not being made apparent elsewhere )? (Or a weird shadow buffer optimization like there was on the old einkfb controller?) Since I barely care about 16bpp anyway, I'm not overly concerned with the fact that I may be mapping double what I actually need. It's certainly still fb memory, so, nothing ever blows up, even with a full memset on it. So far, trusting smem_len hasn't bit me on the ass on Kindle & NTX devices, but I know from KOReader that it's massively broken on PocketBook devices, for instance... EDIT²: It shouldn't bear any relation to landscape/portrait, because it should always at least be equal to line_len * yres_virtual (* bufferN if offset > 0, which it never is), and that's usually been sane in my experience. EDIT³: Fun fact: rotation is weird pretty much everywhere: my desktop's EFI framebuffer happily reports Code: [FBInk] Variable fb info: 1920x1080, 32bpp @ rotation: 0 (Upright, 0°) [FBInk] Fixed fb info: ID is "simple", length of fb mem: 8847360 bytes & line length: 8192 bytes so, 0/U for landscape . (For those doing the smem_len maths at home, yeah, virt dims are 2048, except they're not reported as such, because everything is terrible). Granted, that may or may not be a factor here: Code: zgrep ROTA /proc/config.gz # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set Last edited by NiLuJe; 10-24-2018 at 01:47 PM. Reason: Updated with actual pickel rotation ;).

10-24-2018, 12:30 PM	#228
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	This leads me to another point: I never tried really hard, because I was afraid this would potentially break basically everything else (since, in my case, I'm mostly expected to be running while Nickel is up, and as playing with pickel showed, it doesn't really like having the rug swept from under its feet when the fb mode changes ), but I've only had moderate success (read: none, rotation or yres/xres inversion was always fucked up) in switching to a fb mode/rotation of my choosing via fbset, so I'll be following your efforts with bated breath . Last edited by NiLuJe; 10-24-2018 at 12:39 PM.

10-24-2018, 01:49 PM	#229
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Okay, I think I'm done updating my first answer, so, to recap, in chronological order: Boot: 16bpp, rota 0 (but for us, holding the device, it's a CCW landscape). Probably matches the touch panel, at least on my device. Pickel: 16bpp, rota 2 (for us, CW landscape) Nickel: 32bpp, rota 1 (for us, UR portait, yay!) NOTE: I may be getting my CW/CCW mixed up. This shit breaks my brain ;D. EDIT: Hey, progress re: my second answer. After running pickel, I can get back to the Nickel mode & rota by doing: Code: fbset -geometry 1080 1440 1088 1536 32 (xres/yres/xres_virt/yres_virt/bpp, run fbset with no args to get the proper syntax of the current mode). After which I'm in... Code: [FBInk] Variable fb info: 1440x1080, 32bpp @ rotation: 0 (Upright, 0°) Then... Code: echo 1 > /sys/class/graphics/fb0/rotate After which I'm in... Code: [FBInk] Variable fb info: 1080x1440, 32bpp @ rotation: 3 (Counter Clockwise, 270°) (Yeah, WTH?!) But, finally... Code: echo 3 > /sys/class/graphics/fb0/rotate leads to the expected Code: [FBInk] Variable fb info: 1080x1440, 32bpp @ rotation: 1 (Clockwise, 90°) And Nickel is happy again . EDIT²: A single echo 3 >\| /sys/class/graphics/fb0/rotate does the job . All of this should be reproducible in C with a single (hopefully) FBIOPUT_VSCREENINFO ioctl, and that rotation quirk will hopefully make more sense there without having to devise the rota to set via a shenanigan like 1^2 == 3 (which suspiciously matches target ^ current in my example...) ... Last edited by NiLuJe; 10-24-2018 at 02:11 PM.

10-24-2018, 02:13 PM	#230
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	What all this does the the mxcfb region the eink controller expects is left to the reader to figure out, because brain mushy now >_<". Fire bad. Tree pretty. Last edited by NiLuJe; 10-24-2018 at 02:15 PM.

10-24-2018, 02:31 PM	#231
baskerville Evangelist Posts: 443 Karma: 305160 Join Date: Aug 2015 Device: Kobo Glo HD, Kobo Aura ONE	Thanks, that's insightful. Could you also try echoing 0 and 2?

10-24-2018, 05:13 PM	#232
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	From nickel (1080x1440, 32bpp, rota 1 (CW), fb origin at the top-left corner): 0 -> 1440x1080, 2 (UD), fb origin at the top-right corner 1 -> 1080x1440, 3 (CCW), fb origin at the bottom-right corner 2 -> 1440x1080, 0 (UR), fb origin at the bottom-left corner 3 -> Back to Nickel state. --- From pickel (1440x1080, 16bpp, rota 2 (UD), fb origin at the top-right corner) 0 -> Back to pickel state 1 -> 1080x1440, 3 (CCW), fb origin at the bottom-right corner 2 -> 1440x1080, 0 (UR), fb origin at the bottom-left corner [That's the status at boot] 3 -> 1080x1440, 1 (CW), fb origin at the top-left corner --- So at least that's consistent, and the final rotation equals input ^ 2 Last edited by NiLuJe; 10-24-2018 at 05:15 PM.

10-24-2018, 05:18 PM	#233
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Because this came up very recently in a discussion w/ poire-z, there's another advantage to using the hardware rotation: it allows you to easily take appreciable shortcuts when blitting. On an unrelated note, this was also one of my pet-peeves with 16bpp on Kobo: it makes no goddamn sense without hardware blitting, because RGB565 is a terrible pixel format for software blitting when nothing else ever uses it. 32bpp is at least better, but is still questionable on a device that only has a 16 color palette, which, hey, an 8bpp fb handles just right, just ask Amazon . And it's addressable, which is a plus, because 4bpp fbs are annoying as hell to handle ;p. Last edited by NiLuJe; 10-24-2018 at 05:26 PM.

10-24-2018, 09:43 PM	#234
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	And because of course, something had to keep being mysterious: When attempting to duplicate the boot rotation via pickel+sysfs, while I end up with what appears to be an identical modeset (i.e., 1440x1080, 16bpp @ rotation: 0 (Upright, 0°)), it turns out, not so much. After implementing proper rotation for that "duplicated" modeset in FBInk, and updating KFMon to use that, my welcome message is still not positioned properly... It's no longer upside down and RTL, but it's not positioned properly on the y axis (it's inverted: near the top instead of near the bottom). -_-". (And, AFAICT, no, it's not because pickel manages to change modeset between my init and my first message, because that behaves in yet another way...). EDIT: Hmm. After running another set of experiments with no rotation tweaks at all, it might still be a race with pickel after all, that at least makes some kind of sense given the timing... Last edited by NiLuJe; 10-25-2018 at 11:32 AM.

10-26-2018, 07:06 PM	#235
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Okay, a final comment on the smem_len thing: Someone (@pazos) recently ported FBink to BQ/Cervantes devices (which are based on the same NTX hardware as Kobos), and reported weird softlocks after a screen clear over the stock reading app. I was doing that with a simple smem_len memset. Turns out, when it can (i.e., @ 16bpp), the Qt Embedded driver they (and possibly others) use uses memory from the offscreen buffer to do... stuff. I'm too lazy to dig into this much (c.f., https://github.com/bq/cervantes-qt/b...kfb/einkfb.cpp, size/psize vs. mapsize), so I'll be switching that memset to line_len * yres (and not yres_virtual like I'd like, because apparently Qt starts monopolizing memory potentially earlier than that). AFAICT, the mmap is perfectly fine, though . Last edited by NiLuJe; 10-26-2018 at 07:12 PM.

10-29-2018, 05:52 AM	#236
baskerville Evangelist Posts: 443 Karma: 305160 Join Date: Aug 2015 Device: Kobo Glo HD, Kobo Aura ONE	Regarding the touch coordinates transformation, the mapping is the following for most devices: Code: 0 → Identity 1 → Sxy My 2 → Mx My 3 → Sxy Mx Where S means swap and M means mirror. The mapping for the Aura H₂O Edition 2 Version 1 is: Code: 0 → Mx 1 → Sxy 2 → My 3 → Sxy Mx My The swapping pattern is identical and the mirroring pattern is shifted downward. Hence the only device specific information needed to compute the transformation given the rotation is the center of the mirroring pattern. Last edited by baskerville; 12-02-2019 at 04:28 PM.

10-29-2018, 10:02 AM	#237
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	Neat! I'd be very curious to see what Code: ntx_hwconfig -v -s /dev/mmcblk0 DisplayPanel returns on the H2O²r1 (and anywhere else, as a matter of fact ), I was hoping that'd provide a reliable info regarding the "native" (i.e., hopefully matching the touch panel) rotation... FWIW, on my H2O: Code: DisplayPanel='6.8" Bottom EPD' Last edited by NiLuJe; 10-29-2018 at 10:04 AM.

10-29-2018, 10:20 AM	#238
patrik Guru Posts: 657 Karma: 4568205 Join Date: Jan 2010 Location: Sweden Device: Kobo Forma	Aura HD, 4.8.11073 Code: ntx_hwconfig_ap.c(1110):vserbose level 1 . NtxHwCfg_GetCfgFldStrVal:[WARNING]Config version too old !! Please update config file !! [10] DisplayPanel='6.8" Bottom EPD'

10-29-2018, 10:22 AM	#239
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	So far, so, good, that makes sense, thanks @patrik .

11-02-2018, 03:48 AM	#240
CH23 Bottom Text Posts: 146 Karma: 332882 Join Date: Nov 2016 Device: Kobo Clara HD, Kobo Glo HD	Clara HD, using the KSM build-in terminal: Code: DisplayPanel='6" Bottom EPD'

Advert

Advert

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
PocketBook-KOReader: a document reader for PDF, DJVU, EPUB, FB2, CBZ, ... (AGPLv3)	chrox	KOReader	566	04-19-2024 05:28 AM
KOReader: a document reader for PDF, DJVU, EPUB, FB2, HTML, ... (GPLv3)	hawhill	Kindle Developer's Corner	1268	02-27-2024 11:49 AM
Kindle -- KOReader: a document reader for PDF, DJVU, EPUB, FB2, HTML, ... (GPLv3)	hawhill	KOReader	1219	01-27-2024 02:29 PM
v3 vs. v3+ as a pdf/DjVu reader	hedonism_bot	HanLin eBook	7	11-02-2010 08:16 PM