yam1
-
Posts
74 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by yam1
-
-
How many submissions one allowed to make? Would animated desktops be allowed (not too much CPU)? (Sample animation attached)
-
On 11/5/2021 at 12:53 PM, jernej said:
FYI, if anyone is interested in advancing Armbian support for H616, I just fixed reboot issue on mainline kernel for OrangePi Zero2. In fact, I started collecting H616 patches in hope to create LibreELEC image. Patches can be found here: https://github.com/jernejsk/linux-1/commits/h616-full
Note: U-Boot needs this hack: https://github.com/jernejsk/u-boot/commit/d420184997f302f546bb0862b1774cca6b43fb9a Without it, Linux will hang at loading Panfrost driver.
Trying to use Panfrost on ili9488: I thought the GPU driver can be used to do fast blts and/or triangle draws to a framebuffer and then the SPI device drivers would just scan them out. Do you know if this is the case? AIGLX thinks my ili8488 screen is not DRI2 capable:
Quotepi@orangepizero2:~$ cat /var/log/Xorg.0.log | egrep -i "panfrost|mali|midgard|gpu|dri|drm|software"
[ 17.829] (==) Automatically adding GPU devices
[ 17.829] (==) Automatically binding GPU devices
[ 17.918] X.Org Video Driver: 24.1
[ 17.918] X.Org XInput driver : 24.1
[ 17.923] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 18.011] (**) OutputClass "Panfrost" setting /dev/dri/card0 as PrimaryGPU
[ 18.303] (II) LoadModule: "dri2"
[ 18.303] (II) Module "dri2" already built-in
[ 18.303] (II) Applying OutputClass "Panfrost" to /dev/dri/card0
[ 18.303] loading driver: modesetting
[ 18.303] (==) Matched modesetting as autoconfigured driver 0
[ 18.303] (==) Matched fbdev as autoconfigured driver 1
[ 18.304] (==) Assigned the driver to the xf86ConfigLayout
[ 18.315] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 18.346] Module class: X.Org Video Driver
[ 18.346] ABI class: X.Org Video Driver, version 24.1
[ 18.346] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 18.371] Module class: X.Org Video Driver
[ 18.371] ABI class: X.Org Video Driver, version 24.1
[ 18.371] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 18.371] (II) FBDEV: driver for framebuffer: fbdev
[ 18.546] (II) modeset(0): using drv /dev/dri/card0
[ 18.564] ABI class: X.Org Video Driver, version 24.1
[ 18.565] (II) Applying OutputClass "Panfrost" options to /dev/dri/card0
[ 22.692] (WW) modeset(0): Option "PrimaryGPU" is not used
[ 22.713] (II) Initializing extension DRI3
[ 22.715] (II) AIGLX: Screen 0 is not DRI2 capable
[ 22.748] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 22.750] (II) Initializing extension XFree86-DRI
[ 22.755] (II) Initializing extension DRI2
-
With the mentioned fixes applied, happy to report everything works, except hdmi, wifi, and the other 2 USBs (tested not working with added settings in armbianenv). It is quite usable now as a little x display and screen updates seem to keep up as tested using smtube mpv videos.
-
Note that the patch was for DRM drivers, not FBTFT drivers. You should see in dmesg it is using drmfb. Also ili9486 hardware is itself very slow, the DRM patch would not fix this. It would not make it draw faster than FBTFT drivers. Did you try changing SPI speed to 32mhz? The patch works well with the newer MHS displays that can run up to 128 mhz. For the newer 3.5 MHS displays, you do not need any patches. For the 4.0 MHS displays, you will need a init string patch.
-
On 1/18/2021 at 12:41 PM, yam1 said:
Just another data point, the following code initializes an ili9341 display on DRM, but there is something else wrong with SPI or driver (but tested driver and it works under H6). One could see the display initializes under X, but the mouse pointer is kind of messed up (1st pic), also X terminal is garbled (2nd pic) . X would then eventually shut down because of lack of input device or something else.
Note: Same behavior with fbdev driver.
As an update to my earlier post, I changed the SPI frequency to 16mhz and the display came up showing the desktop (I was using 48mhz - it worked on other H6 boards.) However, the display shut off a little bit after that.
-
Somebody worked on kernel decided to limit the SPI speed to 10mhz, this is found in drivers/gpu/drm/drm_mipi_dbi.c, in routine u32 mipi_dbi_spi_cmd_max_speed(...), it is returning "return min_t(u32, 10000000, spi->max_speed_hz);"
I dont know what was the intention, is min_t supposed to be max_t ?
Anyway, if you change min_t to max_t, it would work, or if you change the constant to something bigger. I changed the constant to 128mhz (128000000) for my keidei, MHS devices.
Here is the patch:
-
Attached is jernej's patch, slightly modified to work with 5.10.13, sorry for posting it here. The overscan issue can be fixed with this tool, https://projects.nwrk.biz/projects/allwinner-tvout/wiki, this was described in this forum but I don't have the link. The washed out (hardware) issue has also been described here and can be easily fixed with a resistor. There are also DRM properties for dealing with TV offsets and sizing issues but I have not figured out where to put them in the user level device tree, does anyone know? (I tried put them under the tve node but didn't work.) The properties are described here: https://www.kernel.org/doc/html/v4.12/gpu/drm-kms.html?highlight=drm tv#existing-kms-properties
Patch was tested to work with zero, and neo...
-
On 1/28/2021 at 5:02 PM, jernej said:
first generate patch from that commit like this and then put it in appropriate folder according to documentation.
Thanks for your effort on this, I got it working on 5.10.12 using pi-zero; the only changes needed were to remove the other definition of sun8i_h3_mixer1_cfg, added back the tve.dts file from the original patch, as well add it to armbianEnv.txt for invocation as described in the original patch.
It is running in dual screen pi-zero; the top screen is a 4.3 inch car monitor, the bottom is a 3.2" ili9341. I haven't tried the PanFrost bit - shouldn't it work on the top screen? Kodi does come up on the top screen.
-
Just another data point, the following code initializes an ili9341 display on DRM, but there is something else wrong with SPI or driver (but tested driver and it works under H6). One could see the display initializes under X, but the mouse pointer is kind of messed up (1st pic), also X terminal is garbled (2nd pic) . X would then eventually shut down because of lack of input device or something else.
Note: Same behavior with fbdev driver.
-
This is using the second ili9341 tiny drm driver (the one not named ili9341) on kernel 5.9.14, running on OrangePi One Plus. Screen seems to be shifted, colors are also off. Seems somewhere in Panfrost it requires the screen to be at least 640 wide and the color depth to be at least 24 or it requires a different set of fonts??? If I disable Panfrost the screen gets back to normal so you can see the whole terminal and the texts are in black instead of yellow and brown.
The following benchmark results are from glmark2 running in full screen mode:
=======================================================
glmark2 2020.04
=======================================================
OpenGL Information
GL_VENDOR: Panfrost
GL_RENDERER: Mali T720 (Panfrost)
GL_VERSION: 2.1 Mesa 20.1.8
=======================================================
[build] use-vbo=false: FPS: 29 FrameTime: 34.483 ms
[build] use-vbo=true: FPS: 40 FrameTime: 25.000 ms
[texture] texture-filter=nearest: FPS: 58 FrameTime: 17.241 ms
[texture] texture-filter=linear: FPS: 52 FrameTime: 19.231 ms
The program crashed after this. It did display the rotating horse and cube for a while. The crash could be because of missing mipp mapping data (???)
The frame rate seems slow (compared to HDMI ?) but the SPI speed is already set to 48 mhz. I dont think it can be set to any higher for this screen (non-mhs). But no issues so far from SPI or screen using this speed.
Do you have any experience on this and would like to comment on how to make it work better?
-
Two things:
The lines should be gpio_out, not in.
The reset line should be 0 for DRM, and 1 for fbdev, just because.
-
I always use a short barrel adapter cable to convert to a standard sized barrel plug (5.5mm x 2.1mm). I would throw these short cables away if when they wear out. It would also save wear and tear on the board connector.
-
On another note, kernel 5.7 or later is somehow automatically switched to use DRM driver for ili9486 displays - this driver is not working. To work around this I made a copy of the fb ili9486 driver with a different name:
update: DRM driver is working (slowly) on 5.9, so may be you don't need this patch any more... fbdev drivers seem to take precedence over DRM drivers, so if you leave this in it would still use the fbdev driver -- for drmfb the initialization string seemed not being honored may be the reason why it's so slow
-
I made a copy of the driver with a different resolution, now it works with 240x240, 1.3", or 1.54", st7789 based tiny displays:
The patch contains the brightness fix as mentioned earlier - the colors seem okay on this type of displays.
-
Anything wrong with the spi driver for rock3328 or the rock64v2 hardware? My spi tft displays are way too slow when compared with h3 boards (5.7 kernel). Any ideas?
-
The colors seem a bit off, I tried fixing it with the following changes. Its a better approximation/mapping and also makes screen brighter but the colors still a bit off. Any ideas?
for (i = 0; i < to_copy; i++) {
+ u16 pixel = vmem16;
+ u16 b = pixel & 0x1f;
+ u16 g = (pixel & (0x3f << 5)) >> 5;
+ u16 r = (pixel & (0x1f << 11)) >> 11;
+
+ u8 r8 = ((r & 0x1F)*4*63)/31 + 3;
+ u8 g8 = (g & 0x3F)*4 + 3;
+ u8 b8 = ((b & 0x1F)*4*63)/31 + 3;
+
+ txbuf[i * 3 + 0] = r8;
+ txbuf[i * 3 + 1] = g8;
+ txbuf[i * 3 + 2] = b8;
+ }
-
Screen blanker only blanks the first screen :-(
-
I finally had to chance to use this feature of debian, it gives me something like the snapshot capability of vmware. The tutorial is well written, all you have to do is to change the keywords required by the current mainline. Everything else works the same:
setenv bootargs "boot=live live-media-path=/live union=overlay persistence persistence-media=removable ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=$...
For persistence, create a USB partition named "persistence" and specify the directories you want to persist in persistence.conf. The USBs would contain all of the snapshot changes. You then decide what to do with the snapshots just like vmware.
-
Picture from Neo Core with 3 ili9341 2.8 screens running at 48 mhz (horizontal splits seems to work better than vertical splits), with mpv playback configuration:
vo=x11
autofit=720x320
geometry=100%x100%
video-aspect=72:32
sws-scaler=fast-bilinear
hwdec=vdpau
hwdec-codecs=all
fs=yes
video-sync=audio
-
Thought you might want to know :-)
-
Here is another version :-)
-
Finally, my very own :-)
-
One noticeable difference is background and menu across both screens, but 20.04 is missing a lot of dependencies like libwebkit-dev which I have not been able to find a substitute.
-
I am releasing this patch in the hope of you may find it useful. I have also included a sample dts file. It seems to work in 48mhz quite well with very few SPI errors. (Note that the pieces of the driver has been around for some time but I have never seen it put together without further work. Hopefully this patch would make it readily usable. I have tested it on 5.5.18 and quite happy with it.)
0001-fbtft-fb_ili9488.patch 1_ili9488.dts
Sample file is for nanopi neo.
Driver also works with 4 inch LCD, MSP4020, MSP4021
Armbian Desktop Wallpaper Contest
in Announcements
Posted · Edited by yam1
I am submitting my **original artwork** for the Armbian Wallpaper Contest.
**Artwork Details:**
- **Title:**Penguin Planets in Armbian Universe
- **Description:**I wrote a little program to create this image. The background, the penguins and the icons can be customized by making small changes to this program. A wall paper generator web page could be made available for this purpose as well. To encourage vendor support for this project, the penguins (icon, penguin size and location) can be customized per vendor needs. Linux penguins as planets is my original idea (I did not find or copy anything from google). Since the image can be easily recomputed, they are not important any more only the idea remains. The background image is found by searching google images for royalty free universe images. Another background image can be substituted easily if need be.
I hereby confirm and certify that this artwork is an original piece created solely by me. By submitting this artwork to the Armbian Wallpaper Contest, I agree to release it under the [Creative Commons Zero (CC0) license](https://creativecommons.org/publicdomain/zero/1.0/legalcode) (CC0 1.0).