Search the Community

Hi, that's great, thanks. I'm working on advanced hdmi-hotplug scripts, you made the baseline some time ago, as I've seen, so that lcd & hdmi can work and switching is possible. In this setup it's also desired to have X11vnc with stable resolutions. That's why I'm on the hotplug issues. In the next days I will work on the WaveShare Display, so that we can also see some content there. I will provide dts/dtbo for this after testing. Are you also interested in X11 xorg.conf.d files for touchscreen & lcd? Thanks, best, Olaf

Hi again, I figured it out. Based on your work, thanks for this, I was able to draft a DTS-File for the ADS7846. Here is a short How-To for all those people, who are interested: In order to compile/decompile DTS/DTBO files, I needed to get the latest version of the DTC (DT-Compiler). This was doable via cloning the git-repo from here: https://git.kernel.org/pub/scm/utils/dtc/dtc.git/ and compiling via "make install". With this DTC one can compile DTS into DTBO and viceversa. Then I build the "rockchip-ads7846.dts" File: /* * Generic Device Tree overlay for the ADS7846 touch controller * */ /dts-v1/; /plugin/; / { compatible = "rockchip,rk3288-miniarm", "rockchip,rk3288"; fragment@0 { target = <&spi2>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&gpio5>; __overlay__ { ads7846_pins: ads7846_pins { rockchip,pins = <5 12 0 &pcfg_pull_up>; }; }; }; fragment@2 { target = <&spi2>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; ads7846: ads7846@1 { compatible = "ti,ads7846"; reg = <1>; spi-max-frequency = <2000000>; interrupts = <12 2>; // high-to-low edge triggered interrupt-parent = <&gpio5>; pendown-gpio = <&gpio5 12 0>; ti,x-plate-ohms = /bits/ 16 <60>; ti,pressure-max = /bits/ 16 <255>; }; }; }; }; What can be seen: The GPIO-PIN for pendown is GPIO5B4 (physical PIN 11). This is encoded in "12" according to the table presented in: https://forum.radxa.com/t/how-to-control-the-gpio/148/5 GPIO5B4 is the standard for WaveShare Displays, and therefore this rebuilds the TouchScreen part for WaveShares. In my case I needed to modify this towards GPIO5C3 (19) in order to work with my touchscreen. Then the DTS file needs to be compiled into a DTBO: dtc -O dtb -o rockchip-ads7846.dtbo -b 0 -@ rockchip-ads7846.dts Then the new kernel and module for ADS7846 (from your work above) needs to be installed. Lastly the armbianEnv.txt needs to be modified to read: "i2c1 i2c4 spi2 ads7846 uart1 uart2" under overlays. Reboot and voila. For the Display-Part itself: one CAN use DTS files for this, like yours, but don't have to, as the ili9x-drivers are built as modules and do accept options from an option-file (see above). With this, it should be possible to power Touchscreens based on ili9x and ads7846. Thanks for your work and help. Can you make sure, that the building of the ADS7846 module is added to the next-kernel permanently, so that we can use it from now on? Thanks, kind regards, Olaf

Hi, sorry for the confusion. I was assuming, that you are going to build a DTS for the ADS7846 and maybe a second one for the ili9x Display to support the WaveShare Display. I do have a WaveShare display and a second one, driver-wise compatible, but using different pins. For the ili-Display I used options in the module-loading to adapt from WaveShare to the other Display with the ili-driver-module. For the ADS I know, that there can't be options in the module, so they need to be used at the DTS. For DTS / DT Overlays I have read half a day how it works, and found with google, that they can be decomplied forth and back. But this doesn't work for me somehow. Still a beginner there. Sorry again, and I do appreciate your help. If you can point me to a guide, how to rebuild the kernel with DTS and so on, that I can follow, I'm willing to learn and try. Thanks in advance, kind regards, Olaf

Hi there, thanks so far. What I got: The touchscreen in my waveshare module is working. The Display itself NOT, also nothing appears. The touchscreen is mapped to /dev/input/event2 and if I "cat" that and touch the screen, something is coming up. That's good. As my original Display is NOT WaveShare and therefore attached the pendown to a different pin, it seems, that this is not working. That's why I've asked for the dts file. I can't decompile the dtbo back to a dts, as the dtc compiler throws errors and aborts. For the display: Same loading here, but nothing to see. [ 15.404331] of_get_named_gpiod_flags: parsed 'pendown-gpio' property of node '/spi@ff130000/waveshare32b-ts@1[0]' - status (0) [ 15.404394] ads7846 spi2.1: spi2.1 supply vcc not found, using dummy regulator [ 15.404438] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/spi@ff130000/waveshare32b@0[0]' - status (0) [ 15.404455] ads7846 spi2.1: Linked as a consumer to regulator.0 [ 15.404470] of_get_named_gpiod_flags: parsed 'dc-gpios' property of node '/spi@ff130000/waveshare32b@0[0]' - status (0) [ 15.430951] ads7846 spi2.1: touchscreen, irq 244 [ 15.431280] input: ADS7846 Touchscreen as /devices/platform/ff130000.spi/spi_master/spi2/spi2.1/input/input2 [ 15.846870] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 32 KiB buffer memory, fps=25, spi2.0 at 16 MHz .... [ 15.402109] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 15.404298] fbtft_of_value: buswidth = 8 [ 15.404303] fbtft_of_value: debug = 0 [ 15.404306] fbtft_of_value: rotate = 270 [ 15.404309] fbtft_of_value: fps = 25 [ 15.404311] fbtft_of_value: txbuflen = 32768 For the ili9340 module I'm using in MY Display the following OPTIONs in modprobe.d/fbtft_device.conf options fbtft_device custom name=fb_ili9341 busnum=2 buswidth=8 speed=48000000 gpios=reset:162,dc:163,led:167 rotate=90 bgr=1 cs=0 How can I access the build system, where I can pull the commit? Any link to that? Or can I grad the things tomorrow by downloading the NEXT-Built? What do you need, to get better infos? Is there a chance to pass parameters to the overlay via armbianEnv.txt? Thanks, best, Olaf

Hi there, thanks for the positive reply. The display is basically like a waveshare model, meaning, when a waveshare works, this will also work. I have no idea about kernel-config and DT overlays, as the AllWinner boards worked with FEX-Files. I have found the following DTS-File: https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/overlays/ads7846-tinker-overlay.dts But unfortunately I have no idea what to do with it.... sorry. I would like to use the IRQ. The ADS7846 PenDown is connected to PIN22, which is GPIO 171. But I have no idea how to bring it to life with the DTS file. Do I need beyond the DT overlay also a module, that can be loaded? Can you help me in the process? Thanks so far, kind regards, Olaf

would this be similar to the waveshare model? Hmmm, kernel config and DT overlay I assume? I've not tried this. If you have the experience, review the kernel config in our github, and see if you can craft a device tree overlay for it. I have ILI9341 and XPT2046 (same interface) screens lying about for other projects, I may be able to give it a try as well. Were you planning on using the IRQ as well?

2 changes are in queue on my workstation, one is u-boot 2018.11, the other is updating the Dev patchset and beginning to iron out 4.19 Kernel. The first I honestly don't see any issues with moving forward, but want people to know about it, the second is a bit of a hairball and I'll need some help with debugging, and in fixing. Detail of changes: U-boot: Currently Meson64 and Odroid C2 are using 2018.05 and 2018.07, respectively. I will be moving all to 2018.11, and eliminating the "specialness" of the Odroid C2 in our build system, so Meson64 will be inheriting the C2 boot script under the "Meson64 name, it will no longer have its own u-boot patch folder/etc. The board will finally be fully integrated into the Meson64 configuration, although it will still have the special Odroid firmware blob (all Amlogic SoC's have their own blobs, so no special changes need made to allow for the C2 to have a different one than the K2) Current Concerns: packaging scripts on 4.14 kernel are not creating a symlinked named "Image" for the updated boot script. I didn't consider that and only caught it today. U-boot is obviously unimpressed. Kernel 4.19: This will eventually become the "Default" kernel, once it has been debugged and proven out, as Amlogic Mainline kernels can now be easily patched with full video decoder support (already done), and Mali support is available (I need to finish integrating that, later date) Current concerns: -HDMI displays seem to be a sore spot, I have 1 that works flawlessly (hilariously a 7" waveshare-like HDMI), while the other needs to be plugged in after boot to work, and an HDMI-DVI adapter one is nonfunctional. (it seems to think it's attached, but no image) - I am getting a million "failed to change cpu frequency: -5" errors again. The clock marked as critical fix is in there, needs verified as it looks different than the old one. - I had to disable CEC entirely to get the system to boot with a display attached, it would fault, reboot, fault, etc. Plugging in a display after boot yielded an oops. No CEC = that problem is gone. Tagging @Neil Armstrong, for tracking if interested/have ideas. I'm using Neil's always helpful meta-meson patchset, these were squirreled away in "next" so I assume they are not complete/some WIP, so this can be some good feedback/etc. No one can break things like an end user.

Here is Armbian support, not Raspbian. https://www.armbian.com/orange-pi-lite/ Check below - there is one Waveshare that is tested and works with Armbian out of the box.

You can get 5" with the same hdmi and touch controller as the 7", I think also from Waveshare.

Hi! SBC : OrangePi Zero 2 + (H3) Distro: ARMBIAN 5.76 stable Debian GNU/Linux 9 (stretch) 4.19.21-sunxi First when I ran : sudo armbianmonitor -u reply is : System diagnosis information will now be uploaded to Please post the URL in the forum where you've been asked for. Now my problem: I am using Armbian for quite a time and it is wonderful. I am trying to connect a waveshare clone 7 inch lcd with a 800x480 resolution, as the EDID information which lcd provides is broken, I have to force EDID firmware for 800x480 which is already available in the /lib/firmware/edid directory , previously it was working in mainline kernel , but now it refuse to load the same as I upgraded to stretch 4.19.21. /boot/armbianEnv.txt: verbosity=1 logo=disabled console=both edid=0 disp_mode=800x480 extraargs=drm.edid_firmware=edid/800x480.bin overlay_prefix=sun8i-h3 overlays=analog-codec usbhost2 usbhost3 rootdev=UUID=b0cad4ec-9479-4799-9d45-6ca4d9b3da22 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068: dmesg : 1.895908] platform HDMI-A-1: Direct firmware load for edid/800x480.bin failed with error -2 [ 1.895916] platform HDMI-A-1: Falling back to syfs fallback for: edid/800x480.bin [ 62.458285] [drm:drm_load_edid_firmware] *ERROR* Requesting EDID firmware "edid/800x480.bin" failed (err=-11) [ 63.867927] platform HDMI-A-1: Direct firmware load for edid/800x480.bin failed with error -2 [ 63.867943] platform HDMI-A-1: Falling back to syfs fallback for: edid/800x480.bin [ 64.141303] [drm:drm_load_edid_firmware] *ERROR* Requesting EDID firmware "edid/800x480.bin" failed (err=-11) if I change the /boot/armbianEnv.txt file as under extraargs=drm.edid_firmware=edid/800x480.bin to extraargs=drm.edid_firmware=edid/800x600.bin dmesg: [ 1.893325] [drm] Got built-in EDID base block and 0 extensions from "edid/800x600.bin" for connector "HDMI-A-1" [ 3.194872] [drm] Got built-in EDID base block and 0 extensions from "edid/800x600.bin" for connector "HDMI-A-1" it works for 800x600 resolution , so maybe kernel is loading 800x600.bin but not 800x480.bin. Kindly suggest me a solution. Best regards

I'm still not completely clear on your goal, I've done 2 touchscreens at one time with the Tinker, one on DSI (RPi screen), and a Waveshare 7" HDMI. Now, I won't pretend to know all of the I/O on the Tinker 100%, but where are you physically accessing the LVDS?

Thanks for the guide! I tried this, only for the touch screen since I am using an HDMI monitor, but it's not working. It is a 5" waveshare clone (v2) I scoped the spi bus and the interrupt pin. I see some strange characteristics. SCLK is fine: MOSI is only driven to ~1v MISO is less than a volt: And the interrupt on PA1 is ~0.5v I am using an orange pi pc plus on 4.14.84 Anyone have some idea of what might be going on?

Hello Maybe it will help someone. I lost a lot of time trying to connect 1-wire to Cubieboard2 via DVK 522 (it has DS18B20 connection on PB10 /gpio 66/ with external pullup). I've done steps in http://linux-sunxi.org/1-Wire with different combination and it doesn't work. In /sys/bus/w1/devices i had only sth like 00-80... 00-40... 00-c00.. without w1_slave file (i was 100% sure of hardware - it works on waveshare debian image) SOLUTION: In /boot/armbianEnv.txt lines needs to be without comments: and that's it ( overlays are created automatically by config so it will be sth like for example this: overlays=mmc2 nand uart2 uart3 uart4 uart5 uart6 uart7 w1-gpio ) other interesting behaviour cat /sys/kernel/debug/gpio gpio-42 ( |w1 ) in hi I don't know why pin 66 ( https://github.com/cubieplayer/Cubian/wiki/GPIO-Introduction ) has number 42 now I've tried to use PC02 http://linux-sunxi.org/A20/PIO#PC02_.2866.29 and also "(position of letter in alphabet - 1) * 32 + pin number" dmesg output [ 18.227575] sun4i-pinctrl 1c20800.pinctrl: unknown pin PB10 # desired pin finally helped INFO: Cubieboard2, DVK522 image: Armbian Stretch mainline kernel 4.14.y (legacy kernel doesn't boot) on SATA drive cat /proc/version Linux version 4.14.84-sunxi (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #3 SMP Sat Dec 1 07:18:41 CET 2018

Hello, did anyone connect this display to orange pi? 3.5 inch RPi LCD V3.0 HVGA 480X320. There is a XPT2046.Drive download : http://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A) Can conclusions not match?

Looks like u-boot 2018.11 is viable for all Meson64 boards, oddly enough USB works on C2 from boot with this U-boot, but now USB on K2 does not. I've got quite a bit of cleaning to do, C2 doesn't need it's own top-level u-boot patch folder/etc. [edit] It looks like CEC is crashing the board, disabling any mention of it in the config makes it boot successfully, however the HDMI doesn't want to come up either, unless you boot without the HDMI plugged in, and plug it in after Linux is up. Then you can have a 4K 30Hz desktop if your monitor is so capable. HDMI --> DVI on my Acer monitor though, a no-go. [edit] My 7" Waveshare HDMI worked from boot.

Thank you Igor. I will test this image. I use OrangePi Win Plus with Waveshare 7 LCD HDMI (C) display (WSVGA resolution 1024x600). Sorry this old theme. I have tried many methods with old image Ubuntu_xenial_default_3.10.107 but Waveshare worked incorrectly. I was glad when new image Ubuntu Bionic began to works with resolution 1024x600 Waveshare display correctly (automatically). Three times I thank the developers for supporting low resolutions in Bionic. I hope it will work sooner or later.

Well, I'm likely the wrong person for such a topic (I don't even own an TV anymore the last one got trashed after some big caps inside dried out and I wasn't comfortable to solder high voltage caps inside a TV - I don't miss it). I watch streams on my Ipad. But if I would go back to streaming on TV I would probably go for an android TV box which gets regular updates (well, this board supports android as well so why not) or something like an apple TV. I happily waste hours in bringing up some IoT stuff or server stuff to my boards, but I wouldn't have the nerves to 'teach my TV' what I expect from it.. If my android box/appleTV doesn't do what it is supposed to do I can piss off their customers service - at least they get payed for it. If it doesn't work on linux I mostly had to piss off people doing this in their spare time (something I don't want) or doing the work on my own to get it working (IMO not worth my time - not experienced to solve such issues in a reasonable time frame). If you know (partly) what you're doing go out and bring up kodi on linux, if you're just a consumer which then complains that "but it doesn't run as smooth as I expected" go for a android box and complain there that it doesn't work, they'll likely just ignore you whereas in 'opensource linux world' someone is again and again polite enough to explain you why *random codec* doesn't run smoothly yet. But we have people here more familiar/interested with such task here. E.g. @JMCC or @balbes150 do amazing work here for multimedia on arm-linux. Besides a waveshare knock off on an RPi3 all HDMIs on my SBCs are still unused.. (you need an HDMI connector? I can unsolder them with a heatgun, I won't miss them... ). The cool kid in those days has a TV box with linux, cause even the uncool kid can buy and set up an android TV box.. If it does the needed research to buy the right board and invest the time needed to bring his board up properly working if you just buy *random crap* to complain after its that it's not perfect.. Please go somewhere else.. for example drinking crafts beer, it's also cool in those days.

My problem is that each time I try to do anything related to LCD over frame buffer I got next error: ioctl FBIOGET_VSCREENINFO: Inappropriate ioctl for device LCDs (ili9341, st7735s) I'm able to test behave exactly the same way -- every time lighted up white screen, but nothing more. I have NanoPi Neo Air with Armbian (5.59 Nanopiair Debian stretch 4.14.65) on it. All packages in system already updated to latest available versions. Problem remains as on stable kernel, same on nightly build. Currently I have: $ uname -a && cat /etc/issue Linux nanopiair 4.14.74-sunxi #330 SMP Mon Oct 8 00:57:54 CEST 2018 armv7l GNU/Linux Debian GNU/Linux 9 \n \l I'm successfully loading SPI: $ grep spi /boot/armbianEnv.txt overlays=spi-spidev usbhost1 usbhost2 param_spidev_spi_bus=0 param_spidev_spi_cs=0 Here is the way I'm trying to load fbtft_device (e.g. Waveshare 1.44 which is st7735s): modprobe fbtft_device name=fb_st7735r speed=16000000 busnum=0 cs=0 gpios=reset:1,dc:201,led:200,cs:67 custom=1 fps=60 bgr=1 custom=1 verbose=3 width=128 height=128 Wiring was already rechecked for few times already. As a result I can see in dmesg: [ 171.665158] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 171.670433] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 171.671639] spidev spi0.0: spidev spi0.0 1000kHz 8 bits mode=0x00 [ 171.671746] spidev spi0.0: Deleting spi0.0 [ 171.672721] fbtft_device: GPIOS used by 'fb_st7735r': [ 171.672735] fbtft_device: 'reset' = GPIO1 [ 171.672739] fbtft_device: 'dc' = GPIO201 [ 171.672743] fbtft_device: 'led' = GPIO200 [ 171.672749] fbtft_device: 'cs' = GPIO67 [ 171.672765] spi spi0.0: fb_st7735r spi0.0 16000kHz 8 bits mode=0x00 [ 171.684388] fb_st7735r: module is from the staging directory, the quality is unknown, you have been warned. [ 172.603112] Console: switching to colour frame buffer device 16x16 [ 172.603392] graphics fb0: fb_st7735r frame buffer, 128x128, 32 KiB video memory, 4 KiB buffer memory, fps=100, spi0.0 at 16 MHz And there is /dev/fb0. But unfortunately next actions can't draw anything on screen: sudo head --bytes 153600 /dev/urandom > /dev/fb0 yes | head --bytes 76800 > /dev/fb0 The only way to get at least some error is to run (from user of from sudo): $ fbset -i -v ioctl FBIOGET_VSCREENINFO: Inappropriate ioctl for device I'll appreciate any help. Thanks.

Purpose: Discuss displays that at least someone has tested and/or use, particularly touchscreens/strange resolutions/sizes/alternative technologies (DSI, parallel TFT, SPI, etc) Goal: Have some kind of "This at least worked with this version at that time" resource. Over and over people post things like "I have a Waveshare <XX.YY.ZZ> and Armbian can't do what the vendor kernel that uses a crap kernel full of security holes and crusty drivers can". So, point them here and say: "By the power of Google, I beseech thee, search!" And I have some random stuff lying around.

hi. i have orange pi lite and http://www.waveshare.com/3.5inch-rpi-lcd-a.htm lcd . i do all things you say . but i see a light white page. please help meeee. please I have a problem when i show screen in lcd touch screen do not work. in other hand if i dont screen on lcd orange pi lite reconginiz touch screen. please help me . i think this problem become from spi.

You need to ask FriendlyArm/WaveShare if they have any. We can merge drivers to the kernel if you come up with a working patch. That's all we can officially do on this subject. Armbian is ready to build out of the kernel tree drivers ... if you have sources and support from Waveshare. For SPI based displays ... it could work.

A coworker of mine gave me a 5 inch hdmi touchscreen (waveshare knockoff). Getting hdmi to work properly on my orangepi pc was done in a few minutes. But the touchscreen drives me nuts. It came with a xpt2046 so I loaded the ads7846 driver I compiled from fbtft. No error messages, but also no response to a touch. It took me a week to finally realize that not the wiring, the driver or Armbian is was the problem, but the touch digitizer was. So I ordered a new one on my favorite Chinese site and installed it on the lcd. Finally I got a response to touching the screen, but I was not able to calibrate it with xinput_calibrator. After manually calibrating it I found out why... When moving my pen over the touch area in a straight line from right to left, the right halve of the screen gives a accurate touch. But when I reach the left halve of the screen the cursor starts moving up.... Disappointed that I received a broken digitizer I ordered a new (different) one from an other store while complaining to the seller of the broken one. I received the other digitizer and replaced the broken one only to find out that the problem still exists... I decided that the xpt2046 was faulty and replaced it with a ads7846. I'm working in a electronics factory and was lucky to find out we had a few on stock. Expecting the problem to be solved now I hooked up the screen and tried. Disappointment all over... Still the same issue. So I am with my hands in my hair... Any help would be greatly be appreciated.

Hi, First of all sorry for my bad English. I am trying play video on my OrangePi Zero2+ H3 and 7inch waveshare touch screen. I couldn't get the touch screen work with Armbian 5.38 - 3.xx kernel. (I downloaded the Armbian Xenial desktop legacy kernel 3.4.y from website. In this version, mpv plays video with hardware acceleration) Then I updated to Armbian 5.44 - 4.xx kernel (I downloaded the Armbian Stretch mainline kernel 4.14.y from website.) then 7inch touch screen started to work but this time no hardware acceleration. It works "mpv vid.mp4" with dropped frames and very high CPU usage. But it gives error when I try to start video with "mpv --vo=vdpau --hwdec=vdpau vid.mp4". It says: "[vo/vdpau] Error when calling vdp_device_create_xll" No matter I tried it doesn't work. I tried to reinstall mpv, vdpau, libump etc (http://linux-sunxi.org/User:Rellla/Armbian). One more thing, there is no /dev/mali file in 5.44. but there was in 5.38. What am I doing wrong? Thanks in advance.

since all of those displays are often produces for RPis, running Raspian... It might be a easy way to test them.. Just hock it up to a RPi with the Waveshare drivers.. I had also once a 5inch waveshare knockoff, worked without issues (on a RPi, don't have it here to test it on an Armbian) despite an annoying pink line which didn't disappear.. Or you spend the extra bucks going for an original.. and yeah, it costs more, but waiting weeks and weeks just to realize that something else went wrong costs you at least nerves, sometime you've to balance what's worth more.. For me, it wasn't that important when the display worked.. so price overruled nerves (and probably ethics too.. )

I wanted to share my workaround of setting the proper resolution on both, console and Xorg: Display: Generic 5 inch 800x480 HDMI "Waveshare V2" clone Kernel: mainline Proper/usual way of doing it: 1. Edit uboot/dtb display variable -> does not work currently because only a few resolutions are supported (848x480 is the closest). 2. Add a new mode with "xrandr" and "gtf or cvt" -> but "cvt 800 480 60" does yield a modeline which totally glitches out the display. Possible workaround: 1. Set linux console to 800x480: "sudo fbset -g 800 480 800 480 32" 2. Edit or create something similar to "/etc/X11/xorg.conf.d/01-armbian-defaults.conf" and add: Section "Device" Identifier "fbdev device" Driver "fbdev" EndSection 3. Start the Xserver. For me this effectively disables the Xserver's self-configuration and thus it looks for the resolution that was set prior by fbset. Since that is set to 800x480, Xserver picks it up. This however also breaks the "randr" extension, so no live screen rotation and stuff, which is a pity. If you want to rotate the screen you have to add the following instead: Section "Device" Identifier "fbdev device" Driver "fbdev" Option "ShadowFB" "true" Option "Rotate" "CW" #Clockwise EndSection So yeah, to conclude - its a pretty hacky solution and someone might hopefully find a more suitable one. Regards