Closed akemnade closed 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).
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?
There, https://github.com/NiLuJe/FBInk/tree/kobo_mainline_id ought to do the trick?
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!)
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
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.
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).
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.
(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) ;).
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).
Note to self: add a dedicated constant for "invalid/unknown/failed", as the cast shenanigans are fugly.
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#
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 ;).
Maybe it is not clear:
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'
all still the Shine 2
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.
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
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 ;).
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.
FWIW, I'm unlikely to go that route, as the vast majority of users should currently not be running mainline ;).
On Kobo Clara HD with 5.17.10 near-mainline-kernel + Debian + user in video group:
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.