download image file of A06 and flash it to sd-card
Yes there is a trick, sometimes the windows aren´t designed to be resized and can´t get smaller than a given threshold. The trick is to right click the window on the taskbar and select move, it will allow you to yank the window up, showing the buttons.
2 Likes
Perfect! This is exactly what I needed!
Two more tricks that work sometimes… Maximize some dialogs re-arranges them so the buttons show up. Also, Alt+F7 allows you to move windows with the cursor keys.
2 Likes
to reach bottom buttons of too large windows/dialogs, try holding alt and then grabbing them somewhere and drag upwards with your mouse.
1 Like
press the Alt key and left mouse on anywhere of the window, then you’ll find can move it to any place.
1 Like
has anyone noticed that the display cuts off a bit of the top of the screen on the DT? is it an overscan issue?
1 Like
With you, me, and @iamcco that makes three who’ve noticed the four-line-skip at the top of the display. I’m hoping that it’s a firmware/software issue, but the peeps at Clockwork are a little busy trying to get the last of the pre-orders out of the door at the moment to investigate. Fingers crossed for an easy fix!
Its an overscan issue, easily fixable. I actually didn’t know I also have it until I tested the transforms to fix it.
You can use xrandr --prop to see your connected displays, in our case is DSI-1
To transform the screen 4 pixels down you should use
xrandr --output DSI-1 --transform 1,0,0,0,1,-4,0,0,1
If you try some values that mess it up more, use
xrandr --output DSI-1 --transform none
Info about the command: xrandr - ArchWiki
3 Likes
Unfortunately, it’s not quite that easy: shifting the display four pixels down via xrandr does, indeed, bring back the missing four pixels at the top of the screen… but makes four pixels disappear from the bottom.
To test, make a plain 1280x480 image with a four-pixel border all the way around. View it full-screen in Viewnior. You’ll see the top part of the border missing. Use xrandr to shift the display down. Go back to Viewnior. You’ll see the top part of the border present, but the bottom part now missing.
In either case, you’re missing four rows of pixels: the display only seems able to show 476 vertical pixels, not 480.
You should adjust the transform for your case.
I made an image and tested, and yes indeed it goes down because I only adjusted -4 pixels on top, but there are more values.
In my case xrandr --output DSI-1 --transform 1,0,0,0,1.01,-4,0,0,1 worked fine. (changed 1 to 1.01) Scaling vertical coordinates by 1.01
Here is a test image for the ones what want to try:
I hope discourse doesn’t resize it(Open it in new tab).
https://man.archlinux.org/man/xrandr.1#RandR_version_1.3_options
That’s a workaround, not a fix: you’re distorting the image in order to squeeze 480 vertical pixels into 476 vertical pixels. The screen is still only showing 476 vertical pixels. Granted, it’s a small difference - but enough to mean nothing will be quite true, and to introduce blurring.
Don’t get me wrong, it’ll do as a workaround for now and I certainly appreciate your effort in figuring out the figures required - but I’d really like to be able to use all 480 lines of the 480-line display!
EDIT:
Here’s a demonstration. This is what text looks like without xrandr scaling, using a pixel-perfect bitmap font:
Same again, using your xrandr settings:
(You’re going to want to click the images to make 'em bigger!)
Look at the third line in the second screenshot: see how it’s got a weird ghosting effect? That’s xrandr's scaling. It’s having to squeeze multiple pixels into one, and it doesn’t do a very good job.
EDIT EDIT:
Here’s a somewhat less subtle demonstration. First shot, the DevTerm showing a 1280x480 PNG with alternating white and black one-pixel horizontal stripes - the photo’s deliberately slightly defocused to avoid moire interference.
It looks, from a distance, like a solid grey colour.
Here’s what xrandr scaling does:
You can see how it’s having to shift lines about as it tries to squeeze 480 pixels into a 476-pixel viewable area - and how it affects focus across the entire image in a repeating pattern.
The first photo, incidentally, offers a potential clue to what’s going on - this time shown full-width, so click to biggen:
See how the very bottom white stripe only starts part-way across the display? That’s not overscan; there’s a different problem at play there. If it were overscan, you’d see full-width stripes across the entire display - just not enough of 'em.
3 Likes
Then to further investigate this and possibly fix it (if comes from software) we would need to ask for the source of the panel, I couldn’t find it
DevTerm/devterm-4.19_v0.1.patch at main · clockworkpi/DevTerm · GitHub panel-cwd686.c should be called.
This kind of struct should be the thing we should check linux/panel-simple.c at master · torvalds/linux · GitHub
Thats my guesses, never went that deep into the kernel, but would be fun.
EDIT: I was looking at the wrong path, apparently the patch contains the source DevTerm/kernel-004-panel.patch at 5465b210e44344e8d8261390b910e46781a7316f · clockworkpi/DevTerm · GitHub
4 Likes
Good find!
I’m thinking it may be related to the vertical sync values, possibly? I’m guessing there’s no easier way to test out other values than editing the source and recompiling each time… Could get tedious!
I do doubt it.
It is probably more in the sequence of obscure and undocumented commands sent to the screen in the screen in
cwd686_init_sequence()
What is really important in the settings are the “display time” the sync time as long as the v and h total are correct will mostly impact the frame rate.
We are in the pure digital domain there, sync are somewhat virtual, we are not driving a CRT monitor where there it would be critical.
3 Likes
I found this https://events.static.linuxfound.org/sites/events/files/slides/brezillon-drm-kms.pdf maybe it provides some insight.
1 Like
No the DRM mode values are reasonable:
static const struct drm_display_mode default_mode = {
.clock = 54465,
.hdisplay = 480,
.hsync_start = 480 + 150,
.hsync_end = 480 + 150 + 24,
.htotal = 480 + 150 + 24 + 40,
.vdisplay = 1280,
.vsync_start = 1280 + 12,
.vsync_end = 1280 + 12+ 6,
.vtotal = 1280 + 12 + 6 + 10,
};
htotal = 694
vtotal = 1308
FPS = clock * 1000 / (htotal * vtotal)
(clock is in KHz)
FPS = 60.87, not perfect 60Hz, but close enough.
But that’s not what could make lines to be missing, and it is not like they are replicated at the bottom, so it is not a sync issue.
The problem is most likely in that code:
+static void cwd686_init_sequence(struct cwd686 *ctx)
{
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
dcs_write_seq(0xF0,0x5A,0x5A);
dcs_write_seq(0xF1,0xA5,0xA5);
dcs_write_seq(0xB6,0x0D,0x0D);
dcs_write_seq(0xB4,0x0A,0x08,0x12,0x10,0x0E,0x0C,0x00,0x00,0x00,0x03,0x00,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x04,0x06);
dcs_write_seq(0xB3,0x0B,0x09,0x13,0x11,0x0F,0x0D,0x00,0x00,0x00,0x03,0x00,0x03,0x03,0x03,0x03,0x03,0x03,0x03,0x05,0x07);
dcs_write_seq(0xB0,0x54,0x32,0x23,0x45,0x44,0x44,0x44,0x44,0x90,0x01,0x90,0x01);
dcs_write_seq(0xB1,0x32,0x84,0x02,0x83,0x30,0x01,0x6B,0x01);
dcs_write_seq(0xB2,0x73);
dcs_write_seq(0xBD,0x4E,0x0E,0x50,0x50,0x26,0x1D,0x00,0x14,0x42,0x03);
dcs_write_seq(0xB7,0x01,0x01,0x09,0x11,0x0D,0x55,0x19,0x19,0x21,0x1D,0x00,0x00,0x00,0x00,0x02,0xFF,0x3C);
dcs_write_seq(0xB8,0x23,0x01,0x30,0x34,0x63);
dcs_write_seq(0xB9,0xA0,0x22,0x00,0x44);
dcs_write_seq(0xBA,0x12,0x63);
dcs_write_seq(0xC1,0x0C,0x16,0x04,0x0C,0x10,0x04);
dcs_write_seq(0xC2,0x11,0x41);
dcs_write_seq(0xC3,0x22,0x31,0x04);
dcs_write_seq(0xC7,0x05,0x23,0x6B,0x49,0x00);
dcs_write_seq(0xC5,0x00);
dcs_write_seq(0xD0,0x37,0xFF,0xFF);
dcs_write_seq(0xD2,0x63,0x0B,0x08,0x88);
dcs_write_seq(0xD3,0x01,0x00,0x00,0x01,0x01,0x37,0x25,0x38,0x31,0x06,0x07);
dcs_write_seq(0xC8,0x7C,0x6A,0x5D,0x53,0x53,0x45,0x4B,0x35,0x4D,0x4A,0x49,0x66,0x53,0x57,0x4A,0x48,0x3B,0x2A,0x06,0x7C,0x6A,0x5D,0x53,0x53,0x45,0x4B,0x35,0x4D,0x4A,0x49,0x66,0x53,0x57,0x4A,0x48,0x3B,0x2A,0x06);//GAMMA2.2
dcs_write_seq(0xC6,0x00,0x00,0xFF,0x00,0x00,0xFF,0x00,0x00);
dcs_write_seq(0xF4,0x08,0x77);
dcs_write_seq(0x36,0x14);
dcs_write_seq(0x35,0x00);
dcs_write_seq(0xF1,0x5A,0x5A);
dcs_write_seq(0xF0,0xA5,0xA5);
}
And good luck to know what it does set. Well you may know if you find what driver the screen do use and the doc for them is public.
1 Like
Just wanted to share another option until there is a real fix -
I had switched my window manager to dwm and noticed the pixels at the top of the menu bar cut off as well. At the time I didn’t see a thread about it in the forum (plus it was visible in some of the official photos), so I padded out the window manager area by 4 pixels to avoid the bar cropping.
It is still just a work around that doesn’t really fix the problem, but the upside is that is doesn’t suffer from the resampling artifacts from xrandr scaling solution. The padding also applies to the dwm’s pseudo full screen windows too.
1 Like
I had switched my window manager to dwm and noticed the pixels at the top of the menu bar cut off as well. At the time I didn’t see a thread about it in the forum (plus it was visible in some of the official photos), so I padded out the window manager area by 4 pixels to avoid the bar cropping.
Would you be so kind as to explain in detail how one could do that?
1 Like