yam1

  • Posts

    69
  • Joined

  • Last visited

Everything posted by yam1

  1. 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.
  2. 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.
  3. 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
  4. 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...
  5. 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.
  6. 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.
  7. 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?
  8. Two things: The lines should be gpio_out, not in. The reset line should be 0 for DRM, and 1 for fbdev, just because.
  9. 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.
  10. 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
  11. 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.
  12. 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?
  13. 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; + }
  14. Screen blanker only blanks the first screen :-(
  15. 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.
  16. 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
  17. Thought you might want to know :-)
  18. Here is another version :-)
  19. Finally, my very own :-)
  20. 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.
  21. 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
  22. I replaced all of my orange pi zeros with them as camera servers - combined with esp32s to serve as remote monitors. The one shown in previous message is a spare one to use as tool chain builder, also can be used standalone.
  23. Here is what I did with one of mine - added $7.5 neo core as standalone terminal with back to back ethernet and serial connections :-)
  24. Upgraded to dev 5.5, SPI errors persist...
  25. I just bought six, now I have to figure out what to do with them.