Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. How many submissions one allowed to make? Would animated desktops be allowed (not too much CPU)? (Sample animation attached)
  3. 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:
  4. 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.
  5. 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.
  6. 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.
  7. 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: drm.patch
  8. 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 zzzz-tv-cvbs.patch Patch was tested to work with zero, and neo...
  9. 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.
  10. 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. 1_ili9341.dts Note: Same behavior with fbdev driver.
  11. 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?
  12. Two things: The lines should be gpio_out, not in. The reset line should be 0 for DRM, and 1 for fbdev, just because.
  13. 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.
  14. 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: 0001-fbtft-fb_ili9486o.patch 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
  15. 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: 0001-fbtft-fb_st7789.patch The patch contains the brightness fix as mentioned earlier - the colors seem okay on this type of displays.
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines