Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Following the suggested process in #477, could we rush in the "are you really sure you want to build fbdev" nagging for Weston 10.0.0 or is it too late?
Thanks for the heads up. Since SimpleDRM got merged, (I still have to compile the kernel because Debian doesn't build it yet) I no longer am going to complain about the fbdev backend going away.
I think the PostMarketOS folks might use it though, although they might be able to use SimpleDRM too (on non x86 platforms? I think)
Seriously, dropping fbdev? Arch just updated to 10.0.0 and now my local spi connected screen no longer works with weston. I have tried the other backends and I get nothing. Are there other flags in the weston.ini that are required to get it to work? I've tried drm and it errors out. This is on arch linux arm running on a RPi v3/4. Used to work under armv7 and aarch64. It still works with X11...
The screen is the AdaFruit PiTFT Plus - 3.5" Resistive touch-screen. The log when started with weston 9 is:
[20:57:54.640] weston 9.0.0 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: 9.0.0[20:57:54.640] Command line: /usr/bin/weston --tty=1 --log=/var/log/weston.log --config=/srv/http/.config/weston.ini --modules=systemd-notify.so[20:57:54.640] OS: Linux, 5.15.21-3-rpi-ARCH, #1 SMP PREEMPT Fri Feb 11 13:59:13 UTC 2022, aarch64[20:57:54.641] Using config file '/srv/http/.config/weston.ini'[20:57:54.641] Output repaint window is 7 ms maximum.[20:57:54.641] Loading module '/usr/lib/libweston-9/fbdev-backend.so'[20:57:54.648] initializing fbdev backend[20:57:54.654] logind: not running in a systemd session[20:57:54.654] logind: cannot setup systemd-logind helper (-61), using legacy fallback[20:57:54.654] Opening fbdev frame buffer.[20:57:54.654] Calculating pixman format from: - type: 0 (aux: 0) - visual: 2 - bpp: 16 (grayscale: 0) - red: offset: 11, length: 5, MSB: 0 - green: offset: 5, length: 6, MSB: 0 - blue: offset: 0, length: 5, MSB: 0 - transp: offset: 0, length: 0, MSB: 0[20:57:54.654] Created head 'fbdev' for device /dev/fb1 (fb_hx8357d)[20:57:54.671] event0 - stmpe-ts: is tagged by udev as: Touchscreen[20:57:54.673] event0 - stmpe-ts: device is a touch device[20:57:54.674] event0 - stmpe-ts: applying calibration: 0.004628 1.099945 -0.038703 -1.114836 0.016171 1.047997[20:57:54.677] event1 - Jabra Evolve2 65 (AVRCP): is tagged by udev as: Keyboard[20:57:54.677] event1 - Jabra Evolve2 65 (AVRCP): device is a keyboard[20:57:54.678] Touchscreen - stmpe-ts - /sys/devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/stmpe-ts/input/input0/event0[20:57:54.678] libinput: configuring device "stmpe-ts".[20:57:54.713] libinput: configuring device "Jabra Evolve2 65 (AVRCP)".[20:57:54.713] Creating fbdev output.[20:57:54.713] Opening fbdev frame buffer.[20:57:54.713] Calculating pixman format from: - type: 0 (aux: 0) - visual: 2 - bpp: 16 (grayscale: 0) - red: offset: 11, length: 5, MSB: 0 - green: offset: 5, length: 6, MSB: 0 - blue: offset: 0, length: 5, MSB: 0 - transp: offset: 0, length: 0, MSB: 0[20:57:54.713] Mapping fbdev frame buffer.[20:57:54.713] fbdev output 480×320 px guessing 60 Hz and 96 dpi[20:57:54.713] associating input device event0 with output fbdev (none by udev)[20:57:54.713] associating input device event1 with output fbdev (none by udev)[20:57:54.713] Output 'fbdev' enabled with head(s) fbdev[20:57:54.713] Compositor capabilities: arbitrary surface rotation: yes screen capture uses y-flip: no presentation clock: CLOCK_MONOTONIC_RAW, id 4 presentation clock resolution: 0.000000001 s[20:57:54.714] Loading module '/usr/lib/weston/kiosk-shell.so'[20:57:54.715] Loading module '/usr/lib/weston/systemd-notify.so'
Have you tried the DRM-backend? Replace fbdev-backend.so w/ drm-backend.so in the ini config file. If you get an error about it, check if you have the correct device nodes under /dev/dri/. Probably you don't have DRM driver loaded. Don't know about RPi3, but RPi4 should definitely work.
Yes, seriously. At this very moment there is active work done in the kernel to allow converting even the last fbdev drivers to DRM.
Still, the fbdev-backend is not gone yet in Weston 10 series. You can still enable it in the build. We wanted to make people really notice that the fbdev-backend is going to go away before it actually disappears, that is why you have you change your build options now if you want to keep on using it a little further.
So, this old dog needs to learn a new trick...
If I could ask for help getting this going, I'd appreciate it. If this is not the place, please let me know.
The fb driver is loaded:
Instead of building the kernel with FB_TFT_HX8357D use/select TINYDRM_HX8357D -- as shown up by @emersion above. Kernel should probe it at boot/load-up, or just enable the tinydrm one and blacklist the fbdev driver at boot-up. If rebuilding the kernel is too inconvenient, you can try rebuilding weston itself, as @pq mentioned, by appending -Ddeprecated-backend-fbdev=true to your meson build flags.
the TINYDRM_HX8357D module is not built in my kernel. I see it in the config and will build a kernel with it to see if I can figure out how to make use of it. Since this is teh direction of the future, I'd rather figure this out now.
also, over here with RPIs, we use dtoverlays and I see there is not yet one that references this module so I'll have to figure that out as well. The only one that exists is the one that references the fb instead of drm.
When I ls /dev/dri, all that is there is the hdmi.
ls -al /dev/dritotal 0drwxr-xr-x 3 root root 100 Feb 10 13:19 .drwxr-xr-x 19 root root 3660 Feb 17 18:38 ..drwxr-xr-x 2 root root 80 Feb 17 18:37 by-pathcrw-rw---- 1 root video 226, 0 Feb 17 18:37 card0crw-rw-rw- 1 root render 226, 128 Feb 10 13:19 renderD128
I can get weston to start and run on weston-1 which is the hdmi and it is fine. How do I get weston to launch on the small screen? It does not seem like it is 'activated' as it is white. Usually when it is detected and ready, it is dark. I have not figured out how to set it up with a dtoverlay, yet, either.
@mvlad Thanks for the help! I had not seen that gentoo page. With info there plus a bit of experimentation, I was able to get something going. To do so, I had to blacklist fb_hx8357d and add hx8357d to /etc/modules-load.d/drm-display.conf to get it to load at boot. With this plus the lines in the config.txt, I was able to get X11 to display and the touch screen works but weston is rotated 90 deg and no amount of futzing with the weston.ini seems to have any effect. I do not yet understand the hdmi output config lines. It seems that the dtoverlay line (which is what I used with the framebuffer driver) is not being read as it is not rotating the display there.
There is not another /dev/dri listing but I guess that is normal. When I start weston, though, it starts on WL1 and now I cannot get it to rotate. but weston does start and it seems to work with the drm backend. I do think that I'll need to write a new dtoverlay, though to load the proper module and not fb_hx8357d. I looked through the code listings and am still a bit lost on that.
Right now, it is rotated 90 degrees and has a black bar at the side and am trying to get that resolved, first. Any ideas?
Edit that line above, and s/rotation/rotate for the second parameter. Anything than 0 should
return an err, you check, and printk if it did not found it. Otherwise, rebuild it and give it a try.
For weston it is because the output is called 'UNNAMED-1'. Change WL1 to UNNAMED-1.
I appreciate your help on this.
I was able to get the rotation to work without editing and rebuilding the module. Apparently the order of overlays in the config.txt is important. Then I list the 'vc4-kms-v3d' ahead of 'pitft-resistive' second, I can use the directive in weston.ini to rotate the screen and it works as expected, no re-building of the module needed.
The problem I am still struggling with is that the 'pitft-resistive' dtoverlay, regardless of where in the config.txt it is forces the load of the framebuffer module:
What I would like to do is make an overlay that loads the proper hx8357d module and not fb_hx8357d if vc4-kms-v3d is loaded. Either that or another workaround to force it to not load fb_* modules but * modules only. I have read a lot on it today and cannot find any concise info I can act on.
as a note, my small spi display has a dri module recently added to the RPi kernel and the overlay has been patched to load the proper driver. There is no longer an impediment to using the vc4 video core which enables the weston drm backend for the newer RPis, at least for this screen and others which use the hx8357d driver.