NiLuJe / FBInk

FrameBuffer eInker, a small tool & library to print text & images to an eInk Linux framebuffer
https://www.mobileread.com/forums/showthread.php?t=299110
GNU General Public License v3.0
315 stars 23 forks source link

wrong ioctl seen on Kobo Clara HD #70

Closed akemnade closed 1 year ago

akemnade commented 1 year ago

On Kobo Clara HD with 5.17.10 near-mainline-kernel + Debian + user in video group:

andi@akepd:~/FBInk$ groups 
andi video
andi@akepd:~/FBInk$ Release/fbink -s
[FBInk] Couldn't find a Kobo version tag (onboard unmounted or not running on a Kobo?)!
[FBInk] [identify_kobo] Couldn't read from `/dev/mmcblk0` (Permission denied), unable to identify the Kobo model!
[FBInk] Detected a Kobo  (0 =>  @ )
[FBInk] This device does not support HW inversion
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 167 dpi
[FBInk] Variable fb info: 1072x1448, 16bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 2176 bytes
[FBInk] Canonical rotation: 2 (Upside Down, 180°)
[FBInk] Fontsize set to 16x16 (IBM base glyph size: 8x8)
[FBInk] Line length: 67 cols, Page size: 90 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Vertical fit isn't perfect, shifting rows down by 4 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Refreshing the screen from top=0, left=0 for width=0, height=0 with waveform mode AUTO and dithering mode PASSTHROUGH (nightmode: N)
[FBInk] [refresh_kobo] MXCFB_SEND_UPDATE_V1_NTX: Invalid argument!
[FBInk] update_region={top=0, left=0, width=1072, height=1448}!
[FBInk] [fbink_refresh] Failed to refresh the screen!
[CLI] Failed to refresh the screen as per your specification!
andi@akepd:~/FBInk$ ls -l /dev/fb0 
crw-rw---- 1 root video 29, 0 Aug 29 18:56 /dev/fb0
andi@akepd:~/FBInk$ xxd /sys/firmware/    
devicetree/ fdt         
andi@akepd:~/FBInk$ xxd /sys/firmware/devicetree/base/
#address-cells   aliases/         clock-ckil/      clock-ipp-di1/   compatible       gpio-keys/       memory@80000000/ name             soc/             wifi_pwrseq/     
#size-cells      chosen/          clock-ipp-di0/   clock-osc-24m/   cpus/            leds/            model            regulator-wifi/  thermal-zones/   
andi@akepd:~/FBInk$ xxd /sys/firmware/devicetree/base/compatible 
00000000: 6b6f 626f 2c63 6c61 7261 6864 0066 736c  kobo,clarahd.fsl
00000010: 2c69 6d78 3673 6c6c 00                   ,imx6sll.
andi@akepd:~/FBInk$ 

MXCFB_SEND_UPDATE_V2 should be sent there (and is done when /dev/mmcblk0 is accessible)

Conclusion the logic of interface detection should be improved.

I think using /sys/firmware/devicetree/base/compatible is the best way to detect the device used (if it is there), if there is kobo,something in there, that is a near-mainline kernel is used and the model can be detected properly. If there is some imx6sl, imx6sll, imx6ull in there, it should be safe to send MXCFB_SEND_UPDATE_V2. To distinguish from upcoming drm drivers (which do not support any freescale ioctl stuff, the availability of /sys/bus/platform/drivers/imxepdc*fb could be checked.

NiLuJe commented 1 year ago

I won't be able to test any of this, but I can push updated code in a branch for you to test ;).

What's the format of /sys/firmware/devicetree/base/compatible supposed to be like? CSV? Is it a guarantee?

EDIT: And, err, because DPI actually matters, what's the full list of devices that can currently be reported in there?

EDIT²: Unless the physical height/width of the panel is actually sane in the variable framebuffer info? (It... is not on NTX kernels, only lab126 does those properly ;p).

akemnade commented 1 year ago

Format can be considered very stable, other programs also use this for device-specific quirks. A list of zero terminated strings, first one more specific to the device, next one more generic, specifying more the processor, e.g. here first string is kobo,clarahd second string is fsl,imx6sll Mainline kernel knows for kobo devices: andi@aktux:~/kobo/kernel$ grep kobo Documentation/devicetree/bindings/arm/fsl.yaml

This list will probably expand, so you might find devices here in future which today only run a ntx 3.0.35 kernel. Electrically, the Kobo Glo HD is a Tolino 2 HD Maybe test for kernel version to decide which ioctl to use? BTW: Screen size (physical and pixel is the same for Kobo Clara HD and Tolino Shine 2/3)

Second string is (imx-based ebookreaders)

NTX devicetree-based kernels have unofficial things for the first string, so you cannot derive the device from it, but the same set as mainline for the second string, so you do not get that much information there, but that is still a hint for the interface, so you can and probably should use things in the unpartitioned space as a fallback.

I can of course help with testing/debugging.

Which imx6 devices do you own, maybe I can help with getting a recent kernel to run there?

NiLuJe commented 1 year ago

There, https://github.com/NiLuJe/FBInk/tree/kobo_mainline_id ought to do the trick?

NiLuJe commented 1 year ago

Which imx6 devices do you own, maybe I can help with getting a recent kernel to run there?

I have... a few (https://www.mobileread.com/forums/member.php?u=69624), but I'm not a hardware tinkerer, so none of 'em have ever been opened, so I don't have serial access, and playing around with custom kernels is not something that I'm confident in doing in those conditions ;). (Thanks, though!)

NiLuJe commented 1 year ago

NTX devicetree-based kernels have unofficial things for the first string

On a Forma, FWIW:

┌─(ROOT@frost:pts/0)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(~)─┐
└─(0.55:27%:00:54:59%:#)── hexdump -C /sys/firmware/devicetree/base/compatible                                                                                                                                                                                                                                                                         ──(Tue, Aug 30)─┘
00000000  66 73 6c 2c 69 6d 78 36  73 6c 6c 2d 6c 70 64 64  |fsl,imx6sll-lpdd|
00000010  72 33 2d 61 72 6d 32 00  66 73 6c 2c 69 6d 78 36  |r3-arm2.fsl,imx6|
00000020  73 6c 6c 00                                       |sll.|
00000024
akemnade commented 1 year ago

On a Tolino Shine 2 with no user access (I could have also called this as root with access to that device) to the unpartitioned space:

[FBInk] Couldn't find a Kobo version tag (onboard unmounted or not using Nickel?)!
[FBInk] [identify_kobo] Couldn't read from `/dev/mmcblk0` (Permission denied), unable to identify the Kobo model via its NTX board info!
[FBInk] Detected a Kobo Glo HD (371 => Alyssum @ Mark 6)
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1072x1448, 16bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 2176 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM base glyph size: 8x8)
[FBInk] Line length: 44 cols, Page size: 60 rows
[FBInk] Vertical fit isn't perfect, shifting rows down by 4 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Refreshing the screen from top=0, left=0 for width=0, height=0 with waveform mode AUTO and dithering mode PASSTHROUGH (nightmode: N)
[FBInk] [refresh_kobo] MXCFB_SEND_UPDATE_V1_NTX: Invalid argument!
[FBInk] update_region={top=0, left=0, width=1072, height=1448}!
[FBInk] [fbink_refresh] Failed to refresh the screen!
[CLI] Failed to refresh the screen as per your specification!

MXCFB_SEND_UPDATE_V2 is expected. It is using NTX stuff where only the plain freescale/nxp api is available. Maybe MXCFB_SEND_UPDATE_V1_NTX should be tied to kernel version 3.0.35? At all it is not a property of the device but of the kernel used. BTW: I think I could add the physical display sizes for newer kernels.

NiLuJe commented 1 year ago

Oh, right, my bad, I mapped the Tolinos to their matching Kobo board, but forgot that the Glo HD wasn't a Mk. 7, so it's using the older API.

I... don't really want to tie anything into the kernel version, as it's potentially as brittle if not more than this (and the new kernels actually support the old API, too). (Also, utsname is annoying ;p).

akemnade commented 1 year ago

It is not an old API, it is a NTX addition to the Freescale/NXP(=the manufacturer of the SoC) API, so it is only there on real NTX kernels. Kobo Glo HD and Tolino Shine 2HD do not differ in the SoC but in the number of buttons (it is different than Tolino Shine 3 vs. Kobo Clara HD) And tomorrow, I or someone else might come up with full support for the Kobo Glo HD.

NiLuJe commented 1 year ago

(Barring the virt_addr shenanigans in the alt data struct), it matches the original freescale implementation on Kindle/PB kernels, too; while the V2 API added support for the dithering params (and the actual v2 of the epdcfb driver), hence my "old/new" approach ;).

Anyway, I can trivially enforce the V2 API when a device is detected via DTB, so that's easy enough to deal with.

When a new device gets added, it'll just be a matter of adding the new codename (like always) ;).

NiLuJe commented 1 year ago

https://github.com/NiLuJe/FBInk/commit/99b9276528bd0bba06367b06df1a947d2d13748b ought to do the trick ;).

(Untested, I'm not on my box, so this was done via the GH web UI :x).

NiLuJe commented 1 year ago

Note to self: add a dedicated constant for "invalid/unknown/failed", as the cast shenanigans are fugly.

akemnade commented 1 year ago

Sorry, I am a bit too creative here, so I am causing trouble again: I am booting here with all the ntx hidden stuff still in place in the unpartitioned space:

andi@debnfs:~/FBInk$ LD_LIBRARY_PATH=Release Release/fbink -s
[FBInk] Couldn't find a Kobo version tag (onboard unmounted or not using Nickel?)!
[FBInk] [identify_kobo] Couldn't read from `/dev/mmcblk0` (Permission denied), unable to identify the Kobo model via its NTX board info!
[FBInk] Detected a Kobo Glo HD (371 => Alyssum @ Mark 6)
[FBInk] Enabled Kobo Mark 7 quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 300 dpi
[FBInk] Variable fb info: 1072x1448, 16bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 2176 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 24x24 (IBM base glyph size: 8x8)
[FBInk] Line length: 44 cols, Page size: 60 rows
[FBInk] Vertical fit isn't perfect, shifting rows down by 4 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Refreshing the screen from top=0, left=0 for width=0, height=0 with waveform mode AUTO and dithering mode PASSTHROUGH (nightmode: N)
andi@debnfs:~/FBInk$ su
Password: 
root@debnfs:/home/andi/FBInk# LD_LIBRARY_PATH=Release Release/fbink -s
[FBInk] Couldn't find a Kobo version tag (onboard unmounted or not using Nickel?)!
[FBInk] Detected a Kobo Touch? (0 => Trilogy? @ Mark 3?)
[FBInk] Enabled Kobo w/o Multi-Touch quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 167 dpi
[FBInk] Variable fb info: 1072x1448, 16bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 6782976 bytes & line length: 2176 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x16 (IBM base glyph size: 8x8)
[FBInk] Line length: 67 cols, Page size: 90 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Vertical fit isn't perfect, shifting rows down by 4 pixels
[FBInk] Pen colors set to #000000 for the foreground and #FFFFFF for the background
Refreshing the screen from top=0, left=0 for width=0, height=0 with waveform mode AUTO and dithering mode PASSTHROUGH (nightmode: N)
[FBInk] [refresh_kobo] MXCFB_SEND_UPDATE_V1_NTX: Invalid argument!
[FBInk] update_region={top=0, left=0, width=1072, height=1448}!
[FBInk] [fbink_refresh] Failed to refresh the screen!
[CLI] Failed to refresh the screen as per your specification!
root@debnfs:/home/andi/FBInk# 
NiLuJe commented 1 year ago

On which device is that? I'm guessing the Shine 2, still?

If it's a Tolino, that won't work, as I don't know the PCB IDs for Tolinos (and have no idea how/if they're mapped to something the stock OS uses that would possibly somewhat resemble what kobo does; but at least having at all them would be a good start ^^); if it's a Kobo, there's something wrong with your NTX HWConfig layout, so I wouldn't mind an actual dump of the raw data ;).

akemnade commented 1 year ago

Maybe it is not clear:

akemnade commented 1 year ago

hwconfig

{m_hdr = {cMagicNameA = "HW CONFIG "
 cVersionNameA = "v2.6"
 bHWConfigSize = 62 '>'}
 m_val = {bPCB = 50 '2'
 bKeyPad = 13 '\r'
 bAudioCodec = 0 '\000'

    bAudioAmp = 0 '\000'
 bWifi = 7 '\a'
 bBT = 0 '\000'
 bMobile = 0 '\000'
 bTouchCtrl = 11 '\v'
 bTouchType = 4 '\004'
 bDisplayCtrl = 7 '\a'

    bDisplayPanel = 6 '\006'
 bRSensor = 0 '\000'
 bMicroP = 0 '\000'
 bCustomer = 0 '\000'
 bBattery = 1 '\001'
 bLed = 4 '\004'
 bRamSize = 3 '\003'
akemnade commented 1 year ago

all still the Shine 2

NiLuJe commented 1 year ago

You wouldn't happen to have a list of the PCB IDs (or the array index for the PCB field in the NTXHWConfig block, at worst) used by all the Tolinos, by chance? (There's a bash script @ /bin/kobo_config on kobos, FWIW).

If the dump you posted is accurate, that would be E60QF0 for this device.

akemnade commented 1 year ago
You find PCB ids in the device trees in the kernel source. I usually note them there. What I know: device PCB IDs bPCB
Tolino Shine 2HD 37NB-E60QF0+4A2 (also seen A3, different wifi) 50
Tolino Shine 3 37NB-E60K00+4A4 (equal to Kobo Clara HD but i.MX6SL vs. i.MX6SLL) 74
Tolino Vision 5 37NB-E70K0M+6A3 (equal to Kobo Libra H2O but i.MX6SL vs. i.MX6SLL) 87

All are shipped with a 3.0.35 kernel and a 2009.08 uboot

NiLuJe commented 1 year ago

Okay, the branch should now handle this case properly; should it ever happen again.

But it won't on your device, because I added the PCB ID for it ;).

akemnade commented 1 year ago

The only thing which might fail now: Old Tolino kernels. But I doubt anybody is going that road without replacing the whole system, since it is android-based.

I still think it is better to first check for the devicetree stuff and then take things from other sources. But anyways, this is still an improvement, it handles more cases than without it.

NiLuJe commented 1 year ago

FWIW, I'm unlikely to go that route, as the vast majority of users should currently not be running mainline ;).