# Help Getting Started with DevTerm **URL:** \ **Category:** DevTerm\ **Created:** [November 17, 2021, 6:02am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392 "2021-11-17T06:02:09Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![rikiwarren](https://avatars.discourse-cdn.com/v4/letter/r/7ab992/32.png) [@rikiwarren](https://forum.clockworkpi.com/u/rikiwarren)\ **Post date:** [November 17, 2021, 6:02am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/1 "2021-11-17T06:02:09Z")
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- ---
**Author:** ![guu](https://avatars.discourse-cdn.com/v4/letter/g/7ab992/32.png) [@guu](https://forum.clockworkpi.com/u/guu)\ **Post date:** [November 17, 2021, 6:23am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/2 "2021-11-17T06:23:54Z")
> [@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 ---
**Author:** ![Petrakis](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/petrakis/32/256_2.png) [@Petrakis](https://forum.clockworkpi.com/u/Petrakis)\ **Post date:** [November 18, 2021, 12:08am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/3 "2021-11-18T00:08:54Z")
> [@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. ---
**Author:** ![rikiwarren](https://avatars.discourse-cdn.com/v4/letter/r/7ab992/32.png) [@rikiwarren](https://forum.clockworkpi.com/u/rikiwarren)\ **Post date:** [November 18, 2021, 6:11am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/4 "2021-11-18T06:11:35Z")
Perfect! This is exactly what I needed! ---
**Author:** ![hotchalupa](https://avatars.discourse-cdn.com/v4/letter/h/4af34b/32.png) [@hotchalupa](https://forum.clockworkpi.com/u/hotchalupa)\ **Post date:** [November 18, 2021, 7:37am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/5 "2021-11-18T07:37:34Z")
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. ---
**Author:** ![rommudoh](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/rommudoh/32/5214_2.png) [@rommudoh](https://forum.clockworkpi.com/u/rommudoh)\ **Post date:** [November 23, 2021, 2:04pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/6 "2021-11-23T14:04:21Z")
to reach bottom buttons of too large windows/dialogs, try holding alt and then grabbing them somewhere and drag upwards with your mouse. ---
**Author:** ![attila](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@attila](https://forum.clockworkpi.com/u/attila)\ **Post date:** [November 23, 2021, 2:46pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/7 "2021-11-23T14:46:11Z")
press the Alt key and left mouse on anywhere of the window, then you’ll find can move it to any place. ---
**Author:** ![ghostwerk](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghostwerk/32/4602_2.png) [@ghostwerk](https://forum.clockworkpi.com/u/ghostwerk)\ **Post date:** [November 24, 2021, 4:23am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/8 "2021-11-24T04:23:36Z")
has anyone noticed that the display cuts off a bit of the top of the screen on the DT? is it an overscan issue? ---
**Author:** ![iamcco](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/iamcco/32/4547_2.png) [@iamcco](https://forum.clockworkpi.com/u/iamcco)\ **Post date:** [November 24, 2021, 4:42am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/9 "2021-11-24T04:42:25Z")
> [@Screen Issues (Was: Display Damaged from Factory - Bad Luck or Common Flaw?)](https://forum.clockworkpi.com/t/screen-issues-was-display-damaged-from-factory-bad-luck-or-common-flaw/7344/4): > > 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… ---
**Author:** ![ghalfacree](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghalfacree/32/5448_2.png) [@ghalfacree](https://forum.clockworkpi.com/u/ghalfacree)\ **Post date:** [November 24, 2021, 9:14am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/10 "2021-11-24T09:14:45Z")
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! ---
**Author:** ![Petrakis](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/petrakis/32/256_2.png) [@Petrakis](https://forum.clockworkpi.com/u/Petrakis)\ **Post date:** [November 24, 2021, 11:26am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/11 "2021-11-24T11:26:18Z")
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](https://wiki.archlinux.org/title/xrandr#Correction_of_overscan_tv_resolutions_via_--transform) ---
**Author:** ![ghalfacree](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghalfacree/32/5448_2.png) [@ghalfacree](https://forum.clockworkpi.com/u/ghalfacree)\ **Post date:** [November 24, 2021, 11:42am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/12 "2021-11-24T11:42:41Z")
> [@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. ---
**Author:** ![Petrakis](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/petrakis/32/256_2.png) [@Petrakis](https://forum.clockworkpi.com/u/Petrakis)\ **Post date:** [November 24, 2021, 1:28pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/13 "2021-11-24T13:28:50Z")
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 ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/6/6e44f8253e5727703d8aaaf3ffa778c03132cbe0.jpeg) Here is a test image for the ones what want to try: ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/c/c6fbd394d4d9f11eb3d87b7fbab0ef8408c697ed.png) I hope discourse doesn’t resize it(Open it in new tab). [https://man.archlinux.org/man/xrandr.1#RandR\_version\_1.3\_options](https://man.archlinux.org/man/xrandr.1#RandR_version_1.3_options) ---
**Author:** ![ghalfacree](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghalfacree/32/5448_2.png) [@ghalfacree](https://forum.clockworkpi.com/u/ghalfacree)\ **Post date:** [November 24, 2021, 1:44pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/14 "2021-11-24T13:44:55Z")
> [@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: ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/d/d81250033064580e8e9f0afd85f4126bba57bb75.jpeg) Same again, using your `xrandr` settings: ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/2/2e5f1da10aaf4ca6e000b7d5e7a8d5b0ba412e1b.jpeg) (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. ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/f/fd5bdf21820548ed912b00d41636ba729a08e9b8.jpeg) It looks, from a distance, like a solid grey colour. Here’s what `xrandr` scaling does: ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/0/076ddd37d9bb052da831bcf53c93e9474da1757b.jpeg) 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: ![image](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/1/16c6749d235b4c66bb4d377437826273264e200b.jpeg) 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. ---
**Author:** ![Petrakis](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/petrakis/32/256_2.png) [@Petrakis](https://forum.clockworkpi.com/u/Petrakis)\ **Post date:** [November 24, 2021, 7:50pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/15 "2021-11-24T19:50:01Z")
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](https://github.com/clockworkpi/DevTerm/blob/main/Code/kernel/devterm-4.19_v0.1.patch#L481) `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](https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/panel/panel-simple.c#L706) 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](https://github.com/clockworkpi/DevTerm/blob/5465b210e44344e8d8261390b910e46781a7316f/Code/patch/armbian_build_a06/patch/kernel-004-panel.patch) ---
**Author:** ![ghalfacree](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/ghalfacree/32/5448_2.png) [@ghalfacree](https://forum.clockworkpi.com/u/ghalfacree)\ **Post date:** [November 25, 2021, 9:27am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/16 "2021-11-25T09:27:15Z")
> [@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](https://github.com/clockworkpi/DevTerm/blob/5465b210e44344e8d8261390b910e46781a7316f/Code/patch/armbian_build_a06/patch/kernel-004-panel.patch) 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! ---
**Author:** ![Godzil](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/godzil/32/60_2.png) [@Godzil](https://forum.clockworkpi.com/u/Godzil)\ **Post date:** [November 25, 2021, 9:57am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/17 "2021-11-25T09:57:42Z")
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. ---
**Author:** ![Petrakis](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/petrakis/32/256_2.png) [@Petrakis](https://forum.clockworkpi.com/u/Petrakis)\ **Post date:** [November 25, 2021, 11:33am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/18 "2021-11-25T11:33:51Z")
I found this [https://events.static.linuxfound.org/sites/events/files/slides/brezillon-drm-kms.pdf](https://events.static.linuxfound.org/sites/events/files/slides/brezillon-drm-kms.pdf) maybe it provides some insight. ---
**Author:** ![Godzil](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/godzil/32/60_2.png) [@Godzil](https://forum.clockworkpi.com/u/Godzil)\ **Post date:** [November 26, 2021, 8:50pm UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/19 "2021-11-26T20:50:52Z")
No the DRM mode values are reasonable: ```auto 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: ```auto +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. ---
**Author:** ![Effix](https://yyz1.discourse-cdn.com/flex029/user_avatar/forum.clockworkpi.com/effix/32/5738_2.png) [@Effix](https://forum.clockworkpi.com/u/Effix)\ **Post date:** [December 15, 2021, 8:09am UTC](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392/20 "2021-12-15T08:09:14Z")
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. ![IMG_1950](https://canada1.discourse-cdn.com/flex029/uploads/clockworkpi/original/2X/c/cfb459e2144e4b92f8bf42516500f79d469c38f1.jpeg) [Next page](https://forum.clockworkpi.com/t/help-getting-started-with-devterm/7392.md?page=2)