Hi all,
Am 20.09.2018 um 00:46 schrieb Michael Mrozek EvilDragon@openpandora.org:
On Mi, 2018-09-19 at 11:03 +0200, H. Nikolaus Schaller wrote:
Well, I'm a bit confused myself here, so maybe aTc can shed some light here.
Here's what I know:
The Pyra uses a Debian-Base OS with Pyra-specific addons (as packages).
The source for the packages can be found on https://dev.pyra-handheld.com
As far as I am aware, aTc uses the Letux kernel with a few patches and a different config... but I have no idea where these are available :/
Yes, I'd like to add the pyra_defconfig to the Letux kernel tree.
There is also a linux-image GIT... but that seems outdated, so I don't think it's this he's using: https://dev.pyra-handheld.com/packages/linux-image-pyra
There's also a U-Boot source, but I'm not sure this is exactly what aTc uses: https://dev.pyra-handheld.com/notaz/pyra-u-boot
Maybe he can let us know :)
https://dev.pyra-handheld.com (requires an account?)
I don't use this resource. I think it is for user-space PyraOS, but someone else should comment on this.
It's mainly for everything related to the Pyra OS, yes. It should contain everything needed to recreate the Debian incl. bootloader and the kernel from scratch.
All packages are there, but it seems the kernel and U-Boot are mising. aTc: Any reason you can't push the kernel / U-Boot sources you're compiling to git?
The GIT doesn't need an account - unless you want to push updates. Simply click on "Explore" at the bottom and choose "All" to see all public projects on the GIT.
So some source of confusion is that low level development (U-Boot, Kernel) is part of the LetuxOS project but what the user sees (PyraOS) is a separate project that cherry-picks some parts of LetuxOS.
To my knowledge, we would use the complete Letux kernel if it fullfilled everything we need (dbp needs aufs in the kernel, which isn't included).
I think we discussed that before and I suggested to use overlayfs which is maintained in mainline and is configured for Letux.
https://en.wikipedia.org/wiki/OverlayFS : "It was merged into the Linux kernel mainline in 2014, in kernel version 3.18.[4][5] It was improved in version 4.0, bringing improvements necessary for e.g. the overlay2 storage driver in Docker.[6] While most Live CD linux distributions used Aufs as of November 2016, Slackware used overlayfs for its live CD.[7]"
https://en.wikipedia.org/wiki/Aufs : "aufs was rejected for merging into mainline Linux. Its code was criticized for being "dense, unreadable, [and] uncommented".[3] Instead, OverlayFS was merged in the Linux kernel.[4][5] After several attempts to merge aufs into mainline kernel, the author has given up.[6]"
So the question for PyraOS is if you want to use something maintained upstream or have to merge in something with unclear future every now and then.
IMHO, the answer depends if aufs provides any feature that overlayfs can't provide or if it is just a matter of modifying some mount commands in dbp to make use of overlayfs.
So if possible and looking at the work-load and low number of developers available, I'd still recommend to switch to overlayfs for PyraOS. It is more future-proof.
But: there also seems to be an alternative for getting aufs:
https://en.wikipedia.org/wiki/Aufs : "Debian "stretch" does not include aufs anymore, but provides a package aufs-dkms, which auto-compiles the aufs kernel module using Dell's dkms." https://packages.debian.org/stretch/aufs-dkms
So it does not need to be merged directly in any kernel tree and it could be made a build/install-dependency of the dbp package (which is also non-standard).
For example the TILER did work up to 4.18.x but is broken since 4.19-rc1. There was some manual rebase conflict resolution involved, so it might be a bug introduced by that. Or it might be a new API mismatch.
Was it really working or simply not complaining when compiling?
Yes. I use it almost every day with Letux-4.18.8. With 4.19-rc it is only partially working (see http://lists.goldelico.com/pipermail/letux-kernel/2018-August/002497.html).
Because with the PyraOS, rotation worked fine with Kernel 4.15, but with 4.18, the framebuffer showed a black picture as soon as we enabled TILER rotation.
Hm. I wasn't aware of. Maybe such bugs should be reported somehow.
The bug I know with 4.19-rc# is that the image is rotated, but you see only a 32x32 (or 64x64?) pixel area of the framebuffer replicated all over the screen. With X11 it seems to be the last updated area (e.g. mouse pointer or clock digit jumping).
It looks like this
http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180828/92434...
After reconsidering this picture, it came to my mind that I did a screenshot and not take a photo (the LCD image looks the same)!
So this means Idid read back the framebuffer. This is wrong (virtual address mapping?) and the TILER itself is still working.
This finding reduces the number of patches and code locations to look at. And I should compare with TILER patch set removed.
Making screen rotation work again is already on the top of my urgency list.
Without rotation, the framebuffer worked.
This might be a setup/config problem then. Needs more analysis and unfortunately I have no idea how PyraOS is trying to do the setup...
BR, Nikolaus