Help Getting Started with DevTerm

[rikiwarren]

I just got my A6 DevTerm, and it’s been a long time since I last used a linux machine.

I’m sure I’ll have a lot of questions, but for right now, are there any useful getting started guides for making the most of the DevTerm?

Also, it seems like a lot of the windows are (not surprisingly) too tall for the screen. This means a lot of the time important buttons are off screen. I can’t seem to resize the windows. Is there a trick to seeing the full window when this happens?

And what’s the best way to get back to a clean install when I (inevitably) mess something up, and want to just start again from scratch?

Thanks!

-Rich-

[guu]

@rikiwarren

And what’s the best way to get back to a clean install when I (inevitably) mess something up, and want to just start again from scratch?

download image file of A06 and flash it to sd-card

[Petrakis]

@rikiwarren

Also, it seems like a lot of the windows are (not surprisingly) too tall for the screen. This means a lot of the time important buttons are off screen. I can’t seem to resize the windows. Is there a trick to seeing the full window when this happens?

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.

[rikiwarren]

Perfect! This is exactly what I needed!

[hotchalupa]

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.

[rommudoh]

to reach bottom buttons of too large windows/dialogs, try holding alt and then grabbing them somewhere and drag upwards with your mouse.

[attila]

press the Alt key and left mouse on anywhere of the window, then you’ll find can move it to any place.

[ghostwerk]

has anyone noticed that the display cuts off a bit of the top of the screen on the DT? is it an overscan issue?

[iamcco]

Screen Issues (Was: Display Damaged from Factory - Bad Luck or Common Flaw?)

I’ve spotted another issue with the screen, and like before this one’s subtle - but once you notice it, it’s impossible not to notice it: the top few rows of pixels are missing. Yes, missing. Easiest way to see it: right-click on the clock, choose Properties, and switch to “LCD”. Note that the entire top segment of the simulated 7-segment LED displays are… not there. At least, they’re not there on my screen. By positioning the cursor at the exact top of my visible screen and taking a screensh…

[ghalfacree]

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!

[Petrakis]

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

[ghalfacree]

@Petrakis

Its an overscan issue, easily fixable. I actually didn’t know I also have it until I tested the transforms to fix it.

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.

[Petrakis]

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

[ghalfacree]

@Petrakis

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

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.

[Petrakis]

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

[ghalfacree]

@Petrakis

EDIT: I was looking at the wrong path, apparently the patch contains the source DevTerm/kernel-004-panel.patch at 5465b210e44344e8d8261390b910e46781a7316f · clockworkpi/DevTerm · GitHub

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!

[Godzil]

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.

[Petrakis]

I found this https://events.static.linuxfound.org/sites/events/files/slides/brezillon-drm-kms.pdf maybe it provides some insight.

[Godzil]

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.

[Effix]

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.