A portrait panel that shows the desktop sideways has two settings, fixed in order: the device-tree panel-timing must match the LCD datasheet, and orientation is set separately in weston.ini with transform=rotate-90 under [output] name=DPI-1. fbset printing zeros is expected, and the mode= line stays commented out on a fixed panel.
A portrait LCD that lights up and fills its glass but shows the desktop turned on its side has two separate settings. They are fixed in a strict order. The panel-timing node in the device tree brings the glass up at its native resolution and refresh rate. The orientation of what gets drawn is a Weston setting, transform under the [output] section of weston.ini. Fix the timing first, then the transform. fbset printing 0.000 MHz is expected on a DRM-driven panel, so that zero line is not where the fault lives.
Why does a native portrait panel show the desktop sideways?
The panel scans its native 240 x 320 glass in the orientation it was built with. Weston draws in whatever orientation it was given. The transform=rotate-90 setting in the [output] section of weston.ini closes the gap once the timing is right.
Rotation is its own job at every layer of a screen stack. The same separation shows up when map zoom and rotation are separate tasks on an HMI. Read the symptom before touching a file:
- Glass filled, picture turned a quarter turn: hactive and vactive suit the panel, and the transform is missing. This is the sideways case.
- Picture squeezed, letterboxed, or pushed to one edge: a mode= line in weston.ini is asking for a mode the panel does not have. Comment it out and restart.
- Rolling, tearing, or unstable picture: the timing numbers are off the datasheet. Recheck clock-frequency and every porch and sync value.
- Geometry right, colors wrong: the bit depth declared in the overlay, normally a bus-format property, disagrees with the panel's 18 bpp wiring. Check it against the datasheet.
Which panel-timing numbers have to match the LCD datasheet?
All of them, line by line: clock-frequency 6,350,000, hactive 240, vactive 320, hsync-len 10, hfront-porch 10, hback-porch 20, vsync-len 2, vfront-porch 4, vback-porch 2. Check each against the panel datasheet before weston.ini is touched.
The active counts set the resolution: hactive 240 with vactive 320 is the native portrait scan. The clock and the totals set the refresh. Datasheets publish minimum, typical and maximum columns for these values, and vendor documentation on adding a custom display states that panels run with a range of timings; aim for the typicals. Two quiet properties matter too. pixelclk-active = 1 picks the clock edge the panel samples on. width-mm = 44 with height-mm = 58 give Weston the physical glass size it uses for dots-per-inch math. Before editing any of it, check the HMI portrait panel fit so the screen is confirmed for portrait duty in the first place.
Does fbset showing 0.000 MHz mean the panel timing failed?
No. fbset reads the legacy framebuffer interface, which on a DRM-driven panel reports the geometry, 240 320 240 320 in your case, with zeros for clock and porches. The zero timing line is expected and the geometry line is what to read.
The stack drives the panel through the kernel's DRM pipeline. Weston queries that pipeline directly at startup. fbset shows the old fbdev view sitting on top, which carries the geometry and leaves the timing at zero. Judge the panel through the DRM entries instead. The sample weston.ini points the way in its own comments: it suggests cat /sys/class/drm/card1-HDMI-A-1/modes to list an output's modes. Swap in your card and output names.
Do you need mode=240x320 in weston.ini on a fixed DPI panel?
Usually no. A panel described in the device tree exposes one mode, and Weston takes it from the DRM output. The mode= key matters on outputs with several modes such as HDMI, so comment the line out and re-add it only if a problem shows.
The mode= key exists for outputs with a choice. The sample file's own comment shows the detailed form with a 146.25 MHz HDMI example for exactly that reason. If you keep the line on a fixed panel, it has to match the timing to the digit. A mode line of 240x320 at 69.1 Hz does, as the arithmetic below shows. A mode line that misses produces the squeezed or letterboxed picture from the symptom list, which is why commenting it out is the first test.
How do you verify the mode line against the panel timing (worked example)?
Multiply the totals and divide. htotal 280 times vtotal 328 is 91,840 pixel clocks per frame, and 6,350,000 divided by 91,840 is 69.1 Hz, the exact refresh a mode line of 240x320 at 69.1 Hz encodes.
Scenario: the overlay in front of you reads clock-frequency = 6,350,000, hactive = 240, hfront-porch = 10, hsync-len = 10, hback-porch = 20, vactive = 320, vfront-porch = 4, vsync-len = 2, vback-porch = 2.
- htotal = 240 + 10 + 10 + 20 = 280
- vtotal = 320 + 4 + 2 + 2 = 328
- clocks per frame = 280 x 328 = 91,840
- refresh = 6,350,000 / 91,840 = 69.1 Hz
Mode line and device tree agree, so the mode= line adds nothing here and can be commented out with the same mode still delivered. If your datasheet's typical clock differs from 6.35 MHz, run the same arithmetic on its numbers; the refresh scales directly with the clock.
How do you set the rotation in weston.ini?
Uncomment transform=rotate-90 in the [output] section whose name=DPI-1 line is already there, in /etc/xdg/weston/weston.ini, and restart the Weston container so the file is read again at startup.
Keep the name=DPI-1 line uncommented. The sample file warns in its own comment that output changes need the name line to take effect. The [output] section and its keys are documented in the weston.ini manual page, and a vendor wiki page on configuring Weston screen orientation walks the same edit in /etc/xdg/weston/. The sample file spells the quarter turn rotate-90. Some builds also accept the short form 90, and 270 for the other direction. Restart Weston after the edit, the process or the whole container on a container image, because the file is read once at startup.
Which way does the image turn with rotate-90 versus rotate-270?
Set rotate-90 first. If the image then lands upside down, change to rotate-270. Use rotate-180 when a right-side-up mount shows an inverted picture. Two restarts decide it at the outside.
Which quarter turn is correct depends on which edge of the glass the mount holds up, so the restart itself is the test. There is no arithmetic for this one, only the observation after the restart.
Recommendation: keep the device-tree timing as the single source of the mode, comment out the mode= line, leave name=DPI-1 uncommented, and set transform=rotate-90 in /etc/xdg/weston/weston.ini; change to rotate-270 only if the first restart lands the image inverted.
How do you confirm what Weston actually enabled?
Read the DRM sysfs entries. cat /sys/class/drm/card*/modes should list 240x320 for the panel output. cat /sys/class/drm/card*/enabled should print 1 for that output once Weston is up and drawing.
A DPI panel exposes one mode, so a single 240x320 line is the expected listing, and status in the same directory should read connected. With the picture upright, check the portrait signage layout fit before loading real content. And if this machine screen is getting a plain notice board beside it, shop-floor display boards run from a memory card with no network in the loop.
Questions
Does the transform change what the panel scans out?
No. The transform turns the image Weston composes before it reaches the output; the panel still scans its native 240 x 320 at the timing in the device tree. That is why the timing is fixed first and the transform second: one moves the mode, the other only moves the picture.
Where does Weston look for weston.ini?
The system copy lives at /etc/xdg/weston/weston.ini, the path vendor documentation names for the screen orientation edit. On a container-based image, edit the copy your Weston container actually sees, then restart the container. Weston reads the file once at startup and keeps running with what it read.
fbset reports RGB565 but the panel is 18 bpp; which one is wrong?
Often neither. The rgba line in fbset, 5/11, 6/5, 5/0, describes the framebuffer format the driver exposes to applications. The depth driven onto the glass comes from the overlay's bus-format property. When the geometry is right and the colors are wrong, check bus-format against the panel datasheet's 18 bpp wiring.
How much does a porch change move the refresh rate?
Directly, through the totals: refresh equals the pixel clock divided by htotal times vtotal. On the 280 x 328 timing here, widening vfront-porch from 4 to 8 pixels makes vtotal 332, so 6,350,000 / (280 x 332) = 68.3 Hz, a 0.8 Hz drop from 69.1 Hz.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.