search

redrathnure / armbian-mkspi

Armbian Linux Build Framework
https://www.armbian.com
GNU General Public License v2.0
95 stars 12 forks source link

Need help with IPS50 configuration on MKS SKIPR #13

Open EmJay276 opened 1 year ago

EmJay276 commented 1 year ago

Hi,

has anyone gotten the IPS50 working? I am running Armbian_23.05.0-trunk_Mkspi_bullseye_edge_6.1.28.img which works perfectly with the MKS SKIPR. The touch is working fine (it is reacting to the input), I also have background light, but no image showing up.

Thanks in advance!

EmJay276 commented 1 year ago

I think it has to do something with the resolution of the IPS50 (800x480)

Using the provided previous mks image MKS-PI-Armbian_22.05.0-linux_5.16.20-20220726.img, the display does NOT work. Using the newest image Armbian-makerbase-k5.16.20-EN-20230301.img the display works.

The Changelog of the Armbian-makerbase-k5.16.20-EN-20230301.img states:

Modification: 
1. Add support for the some resolution for HDMI, include MKS IPS50 LCD

Source: https://drive.google.com/drive/folders/1tTuSvF9OL2qtPXElau8YOXn2sWbdxa9e

redrathnure commented 1 year ago

@EmJay276 welcome to the reality full of as*** companies who ignore all license agreements. Our chinese friends neither share Armbian sources nor explain details of their kernel patches. And ignore all requests around this topic. So we may only guess what does " Add support for the some resolution for HDMI, include MKS IPS50 LCD" mean.

In theory it's possible to prepare kernel patches to support your special HDMI resolution. However for me it's quite problematic because I have no hardware for testing. Second option would be switching to vendor who cares more about their products and customers support. Perhaps you would pay bit more, but it would work as "plug&play" and you would get better support in case of problems.

Sorry to say, but using cheapest hardware from companies like MKS is always gambling. Sometimes you win (like relatively easy to build for MKS PI and SKIPR boards) however sometimes you stuck...

EmJay276 commented 1 year ago

Can you give me a hint where I need to apply some changes to build the image for a special HDMI resolution? Then I can test it with my hardware here.

redrathnure commented 1 year ago

Perhaps in drivers/video/hdmi.c and include/linux/hdmi.h files. E.g. see https://github.com/redrathnure/armbian-mkspi/commit/59d0ff9e99ae883d4f5589fe0924ec70b048df2f

EmJay276 commented 1 year ago

Yeah i propably need the 5:3 aspect somehow.

I got the edid info of the IPS50, if anyone needs them

`edid-decode < /sys/class/drm/card0-HDMI-A-1/edid` ``` mks@mkspi:/boot$ edid-decode < /sys/class/drm/card0-HDMI-A-1/edid edid-decode (hex): 00 ff ff ff ff ff ff 00 32 8d 19 86 03 00 00 00 01 19 01 03 80 00 00 78 0a ee 91 a3 54 4c 99 26 0f 50 54 21 08 80 81 c0 81 00 81 40 81 80 95 00 a9 c0 a9 40 d1 c0 d0 0b 20 a0 30 e0 2d 10 32 46 e3 04 00 00 00 00 00 1e 66 21 50 b0 51 00 1b 30 40 70 36 00 00 00 00 00 00 1e 00 00 00 fd 00 18 4b 1a 51 17 00 0a 20 20 20 20 20 20 00 00 00 fc 00 41 4e 48 55 41 0a 20 20 20 20 20 20 20 01 20 02 03 30 c1 49 04 13 01 02 03 11 12 1f 10 23 09 07 07 83 01 00 00 02 00 0f e3 05 03 01 72 03 0c 00 40 00 80 1e 20 d0 08 01 40 07 3f 40 50 90 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 00 00 00 00 00 00 89 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: LTM Model: 34329 Serial Number: 3 Made in: week 1 of 2015 Basic Display Parameters & Features: Digital display Image size is variable Gamma: 2.20 RGB color display First detailed timing is the preferred timing Color Characteristics: Red : 0.6396, 0.3300 Green: 0.2998, 0.5996 Blue : 0.1503, 0.0595 White: 0.3125, 0.3291 Established Timings I & II: DMT 0x04: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz DMT 0x09: 800x600 60.317 Hz 4:3 37.879 kHz 40.000 MHz DMT 0x10: 1024x768 60.004 Hz 4:3 48.363 kHz 65.000 MHz Apple : 1152x870 75.062 Hz 192:145 68.681 kHz 100.000 MHz Standard Timings: DMT 0x55: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz DMT 0x1c: 1280x800 59.810 Hz 16:10 49.702 kHz 83.500 MHz DMT 0x20: 1280x960 60.000 Hz 4:3 60.000 kHz 108.000 MHz DMT 0x23: 1280x1024 60.020 Hz 5:4 63.981 kHz 108.000 MHz DMT 0x2f: 1440x900 59.887 Hz 16:10 55.935 kHz 106.500 MHz DMT 0x53: 1600x900 60.000 Hz 16:9 60.000 kHz 108.000 MHz (RB) DMT 0x33: 1600x1200 60.000 Hz 4:3 75.000 kHz 162.000 MHz DMT 0x52: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz Detailed Timing Descriptors: DTD 1: 800x480 60.000 Hz 5:3 31.500 kHz 30.240 MHz Hfront 50 Hsync 70 Hback 40 Hpol P Vfront 30 Vsync 3 Vback 12 Vpol P DTD 2: 1360x768 60.015 Hz 85:48 47.712 kHz 85.500 MHz Hfront 64 Hsync 112 Hback 256 Hpol P Vfront 3 Vsync 6 Vback 18 Vpol P Display Range Limits: Monitor ranges (GTF): 24-75 Hz V, 26-81 kHz H, max dotclock 230 MHz Display Product Name: 'ANHUA' Extension blocks: 1 Checksum: 0x20 ---------------- Block 1, CTA-861 Extension Block: Revision: 3 Underscans IT Video Formats by default Basic audio support Native detailed modes: 1 Video Data Block: VIC 4: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz VIC 19: 1280x720 50.000 Hz 16:9 37.500 kHz 74.250 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 2: 720x480 59.940 Hz 4:3 31.469 kHz 27.000 MHz VIC 3: 720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz VIC 17: 720x576 50.000 Hz 4:3 31.250 kHz 27.000 MHz VIC 18: 720x576 50.000 Hz 16:9 31.250 kHz 27.000 MHz VIC 31: 1920x1080 50.000 Hz 16:9 56.250 kHz 148.500 MHz VIC 16: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz Audio Data Block: Linear PCM: Max channels: 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Speaker Allocation Data Block: FL/FR - Front Left/Right Unknown CTA-861 tag 0x00, length 2 00 0f '..' Colorimetry Data Block: xvYCC601 xvYCC709 Vendor-Specific Data Block (HDMI), OUI 00-0C-03: Source physical address: 4.0.0.0 Supports_AI Maximum TMDS clock: 150 MHz Extended HDMI video details: 3D present 3D-capable-VIC mask present Base EDID image size is in units of 1 cm 3D: Side-by-side (half, horizontal) 3D: Top-and-bottom 3D VIC indices that support these capabilities: VIC 4: 1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz VIC 19: 1280x720 50.000 Hz 16:9 37.500 kHz 74.250 MHz VIC 1: 640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz VIC 2: 720x480 59.940 Hz 4:3 31.469 kHz 27.000 MHz VIC 3: 720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz VIC 17: 720x576 50.000 Hz 4:3 31.250 kHz 27.000 MHz VIC 16: 1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz SVD Index 10 is out of range SVD Index 11 is out of range 3D VIC indices with specific capabilities: VIC 3: 720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz (frame packing) VIC 17: 720x576 50.000 Hz 4:3 31.250 kHz 27.000 MHz (frame packing) SVD Index 10 is out of range (frame packing) SVD Index 11 is out of range (frame packing) Detailed Timing Descriptors: Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e '................' Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c '................' Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1e '................' Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 '................' Checksum: 0x89 ```
redrathnure commented 1 year ago

I may try to prepare the patch for 5x3 ratio when have a free time. Actually return back already removed patch :) Which disctro are you using?

EmJay276 commented 1 year ago

I am using Debian (bullseye) 6.1

EmJay276 commented 1 year ago

The display is recognized with the correct resolution, but won't show anything. On a PC I need to change the resolution manually to 800x480 (recommended) to get it show up. I'm not sure if the display is just not reporting correctly via edid

redrathnure commented 1 year ago

@EmJay276 please try https://drive.google.com/file/d/1AIW7qkUPTo1pWFy4QJYo1MkCJ02PnUrB/view?usp=drive_link image. If it works I will try to fix and prepare edge image.

EmJay276 commented 1 year ago

Unfortunatly it still does not work :(

~~I friend of mine has also the SKIPR board, but a 480x320 HDMI screen (not the TS35). He is using the Armbian_23.05.0-trunk_Mkspi_bullseye_edge_6.1.28.img and has to set extraargs=video=480x320@60 in /boot/armbianEnv.txt, then the screen works perfectly. (Default is 1080p in your image) But mks@mkspi:~$ cat /sys/class/graphics/fb0/modes still reports U:800x480p-0, same es for me.~~

I think the IPS50 needs some special setting :/

Edit: Sry I missunderstood something, he has a SPI display.

redrathnure commented 1 year ago

Too bad...

EmJay276 commented 1 year ago

I could set the resolution to 800x480 via extraargs=video=800x480@60 in /boot/armbianEnv.txt and connect a regular HDMi monitor and get an output.

EmJay276 commented 1 year ago

Edit: I am using Armbian_23.05.0-trunk_Mkspi_bullseye_edge_6.1.28.img

A new mode just "appeared" for this display

cat /sys/class/drm/card0-HDMI-A-1/modes
800x480
640x480

Setting extraargs=video=HDMI-A-1:640x480@60e in /boot/armbianEnv.txt shows an image grafik

EmJay276 commented 1 year ago

With your new provided image I get

mks@mkspi:~$ cat /sys/class/drm/card0-HDMI-A-1/modes
1920x1080
1920x1080
1920x1080
1600x900
1280x1024
1280x960
1152x864
1280x720
1280x720
1280x720
1024x768
800x600
720x576
720x576
720x480
720x480

I will install klipperScreen and report. The other resolution also did not show the terminal (the mks image does) therefore, I thought it does not work

redrathnure commented 1 year ago

Just FYI: there are new release with 6.3 kernel.

EmJay276 commented 1 year ago

I already say the new relase, but had no time yet to test it. But im on it, I realy wanna get the display working.

mikaelml commented 1 year ago

I too am experimenting with the IPS50 display. I am currently running the latest edge build (Armbian_23.08.0-trunk_Mkspi_bullseye_edge_6.3.11.img.xz)

Weirdly enough, on my side it is the 848x400 resolution that seems to work (I was able to have it work in both terminal and KlipperScreen with that resolution). However similar to the image above, the display output is cropped (as it cannot show the last 48 pixels wide, thus making some part of the image not shown in KlipperScreen).

cat /sys/class/drm/card0-HDMI-A-1/modes
1024x768
800x600
800x600
848x480
640x480

Also something that I don't understand is that my edid file is empty (0 bytes)

 ls -al /sys/class/drm/card0-HDMI-A-1/edid
-r--r--r-- 1 root root 0 Jul 10 00:20 /sys/class/drm/card0-HDMI-A-1/edid
mikaelml commented 1 year ago

So after more experimentation I was still not able to make the display work in its native resolution. However with the fact that we can run it at 848x480 instead of 800x480, some workarounds are available if the goal is only to have a working KlipperScreen.

You can add the following lines to the KlipperScreen config file (ig: ~/printer_data/config/KlipperScreen.conf):

[main]
width: 800

The only issue with that workaround is that the touchscreen calibration will be slightly off (especially on the far right of the screen). However that can be solved by tweaking the Coordinate Transformation Matrix for the touchscreen input by passing it the X scale factor of 800 / 848 (0.943396). You can test that by running the command DISPLAY=:0 xinput set-prop "wch.cn USB2IIC_CTP_CONTROL" --type=float "Coordinate Transformation Matrix" 0.943396 0 0 0 1 0 0 0 1, then test the screen accuracy (I found that the Console screen of KlipperScreen is good for that as it shows the cursor).

If those settings are good, you can then create an xorg config file in /etc/X11/xorg.conf.d/ (eg: 99-calibration.conf) that will always apply that transformation matrix.

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "wch.cn USB2IIC_CTP_CONTROL"
        Driver "evdev"
        Option "TransformationMatrix" "0.943396 0 0 0 1 0 0 0 1"
EndSection

So in the end even if the display is technically not running at its native resolution of 800x480, with those 2 steps it pretty much looks like it is running at native resolution from KlipperScreen.

redrathnure commented 1 year ago

Looks like you guys have display with non standard HDMI resolution.

There are few threads which I found and which might be helpful:

And few more remarks:

EmJay276 commented 1 year ago

@mikaelml Your solution works for me perfectly ❤️ (with the 6.1 image, I don't want to install a new image right now). @redrathnure It's (currently) a workaround, but I am fine with it. If you want to add it to the Readme, fell free.

IPS50 HDMI Display

The Image does not support the IPS50 display (5 inch HDMI IPS - 800x480) out of the box. Reasons are unclear. This is a workaround to get the display running.

  1. Connect to the printer via SSH
  2. Open boot config sudo nano /boot/armbianEnv.txt
  3. Add the line extraargs=video=HDMI-A-1:848x480@60e. The screen will be rendered a bit wider than the display is (48px to be precise).
  4. Open screen calibration sudo nano /etc/X11/xorg.conf.d/99-calibration.conf
  5. Add rescaling for the touch input (factor 800/848 = 0.9433969) 
    Section "InputClass"
    Identifier      "calibration"
    MatchProduct    "wch.cn USB2IIC_CTP_CONTROL"
    Driver "evdev"
    Option "TransformationMatrix" "0.943396 0 0 0 1 0 0 0 1"
EndSection
  6. Specify the correct width in the KlipperScreen config file ~/printer_data/config/KlipperScreen.conf (this can be done via the mainsail web interface too). By adding width (and height). Ensure you add the lines above #~# --- Do not edit below this line. This section is auto generated --- #~# ! 
    [main]
width: 800
height: 480   # optional
  7. Reboot

Now the display should show the correct sized KlipperScreen.

NexGen-3D-Printing commented 1 year ago

I tried all that, but I have a black strip down the left side of the screen and the entire display is offset to the right with a strip missing, tested every image including the trunk images, nothing will work for me, only the newer images from MKS will work, and I really don't want to run those, very latest one Kernel panics and wont even boot, I would love it if they just released a clean Debian image.

NexGen-3D-Printing commented 1 year ago

Just an FYI, what ever it is that makes the display work, it's in the "image" file on the boot partition from makerbase, if I copy that file across to one of the images in this repo, then the screen comes to life straight away.

NexGen-3D-Printing commented 1 year ago

I have caved and I'm forced to use the MKS image, but I went straight in and removed the mks user and all files, changed the root password, location and host name, created a new user and now setup everything myself, if someone else that has more time figures this out, then I will jump back.

On a side note, I had a hard time getting the makerbase image to update to a local source, it seems to be locked to a Chinese mirror "Aliyun", and manually changing the mirror would result in apt hanging and not fully completing, I had to force kill the update and go straight to upgrade, which worked, not sure what the hell is going on, but I really don't like this sort of behaviour.

EmJay276 commented 1 year ago

I tried all that, but I have a black strip down the left side of the screen and the entire display is offset to the right with a strip missing, tested every image including the trunk images, nothing will work for me, only the newer images from MKS will work, and I really don't want to run those, very latest one Kernel panics and wont even boot, I would love it if they just released a clean Debian image.

Did you rotate your screen by 180 degree?,

On a side note, I had a hard time getting the makerbase image to update to a local source, it seems to be locked to a Chinese mirror "Aliyun", and manually changing the mirror would result in apt hanging and not fully completing, I had to force kill the update and go straight to upgrade, which worked, not sure what the hell is going on, but I really don't like this sort of behaviour.

I had to purge some intermediate update files too (don't know anymore what I did exactly), then it took like 10 min for sudo apt-get upgrade, after that it worked fine for me with the MKS image.

NexGen-3D-Printing commented 1 year ago

No the screen is in the default orientation, the 180 flip was another can of worms I decided to avoid so modified the printer mounting arrangement instead, I still hope that someone can workout what they did in the "image" file on the boot partition as I would prefer to run redrathnure's image.

Yes updating the MKS image was a similar process for me, its now working fine, not sure if this was malicious or just a side effect of using someone else's operating system, most likely the later.

I have one of redrathnure images running with a MKS 3.5" display on the SKIPR and it works flawlessly, fast booting, screen works, and in my opinion, is better than the mks image, I wrote this guide as well, which is now useless for the 5" display: Setup Klipper on the SKIPR

NexGen-3D-Printing commented 1 year ago

Well for anyone else who runs into this little issue, the correct fix is to prevent the issue, DONT BUY THIS TOUCH SCREEN, instead, get something else that will just works.

To fix the issue after the fact, is to remove the screen from you printer, drop it in the bin, and go buy one that actually works properly, like a Waveshare HDMI screen or similar.

Having to do a hand stand with one hand tied behind your back while balancing the entire collection of Isaac Asmov's books on you right foot while whisling the music from the OG Doom game to make the screen do its most basic function, is just total BS, we need to stop handing over cash to companies that release garbage with next to garbage documentation.

goodwin commented 1 year ago

@NexGen-3D-Printing the problem is not with this screen, or with MKS, or with this specific build of amrbian. the problem is that Rockchip kernel has fd up hdmi support. I did try this screen with rpi - it works fine. with x86 it also works fine. and also it works fine with rockchip "legacy" kernels of 4.4 branch. But later they made a lot of changes into HDMI support. And now it can't handle a wide range of non-popular pixel clocks for HDMI (that's why 800480 does not work - it is not across hardcoded table of pixelclocks, as rockchip supports just few of them)

goodwin commented 1 year ago

So having ANY rockchip SBC + any screen that uses not "common" resolution (read - not regular PC monitor) will give you same headache

redrathnure commented 1 year ago

Hi here, just a few remarks regarding the latest updates.

"image on the boot partition" is a kernel. Means MKS has some kernel patches to make your HDMI screens working. According to license terms they have to open these patches.... however chinese engineers are not hurry up with back contribution and are pretty bad with following of license terms. Pretty usual story, unfortunately.

What we may do in this situation:

  1. Use MKS images. I also tried to "cleanup" native MKS images, but also facing an issue with chinese mirrors and some crap, which is hard to remove. Basically this is main reason why this repo exists. So, if you do not care about your privacy and do not care about updates, then yes, it's easiest option. Otherwise please forget about MKS images (IMO)

  2. Trash your HDMI screen and bay "normal" one. Also good option, if you may afford it. However please see Option 3. And may be it's better to donate it for experiments instead just moving to bin:)

  3. It should be possible to find or develop kernel patches to make it worked. I personally have a bit of optimism here because

    a) this screen works on the other platforms and/or other images, which means kernell is able to support this hardware

    and b) sorry, but I do not believe that MKS engineers invent something new. Usually they just steal take already existed solutions with slightly rebranding. And this (theoretically) means we may find similar hardware with better support and reuse/port the kernel patches. E.g. see story with Renegade ROC-RK3328-CC VS MKS PI boards.

So, what may be helpful here:

  1. Is it works with other boards? Raspberry PI, Orange PI or any other Linux (petter Armbian based) OS.
  2. How this screen is identified on the working platform?
  3. Photos of PCB, controller or any other info which help to identify used hardware.
  4. Perhaps we may find screen with similar resolution or/and similar controller but with better support. Or at least specs for the controller.

Unfortunately it pure theoretical speculations, because I do not have this hardware on the hands and I am not so familiar with HDMI kernel part. Just a few ideas which flying in my head.

hg42 commented 11 months ago

Hi all,

I have a 7 inch 800x480 HDMI LCD. Interstingly it doesn't even work with MKS image. Not sure if the LCD worked with the images from this repo. I tried it very early, even before the MKS image, but I tested only with a USB-HDMI-Adapter (being a virtual screen on my PC in a webcam viewer).

According to the thread here the MKS kernel should work?

I currently use a standard armbian image for rockchip64.

If I use a video=... with a mode that is listed in the modes file of the HDMI-A-1 tree then it works. There is no 800x480, but e.g. 1024x768 or 848x480 work. my LCD is scaling automatically, so I only loose some sharpness.

BUT... I have to switch the screen off and on once (via a button on my usb hub).

This may be the case, because I power the LCD via the USB cable for the touch device. Maybe the power comes up after the hdmi driver started. I once tested with an additional power supply on the second usb port on the LCD (that one seems to be only for power) and as I remember it didn't help, but perhaps I had another problem at that time, I really should test it again.

I remember, that a real Pi 2B had the same behaviour and I added some hdmi options in the config.txt, I think that forced the hdmi mode. Or was it disabling dpms?

I tried to use uhubctl to do a power cycle, but it doesn't really switch the power (not sure if it does other things like a reset or similar).

hg42 commented 11 months ago

ok, I read a bit about video=...

First I read somewhere, that extraargs="a b c" (with quotes) doesn't work, but extraargs=a b c does. I didn't exactly verify this, but at least it takes my line without the quotes.

One case of my power on/off problem seems to be simply, that it's not selecting the HDMI-A-1 without saying extraargs=video=HDMI-A-1 Some of my tests didn't have the line at all. May be adding the e for enable at the end is also necessary. I tried using the additional power supply, but it did not change anything.

Next I tried your image. It shows the 800x480 mode, which should work. But it doesn't. The screen constantly goes off and on.

But... I noticed that only using video=HDMI-A_1:e works, and it uses mode 1024x768. And it's scaled. May be it's an analog signal, so it's scaling it? Will try adding the D for digital output, later.

When I use video=HDMI-A-1:640x480e it works somehow, it's sharper, so I think it's digital or at least exactly fitting the pixels. The output seems to be cut (black area on the right). I am currently looking for a way to test graphical output with a raster or similar, not sure how I can do it. May be using an image and some image viewer for the frame buffer. Or directly writing to the fb device? At first I will try Xorg.

hg42 commented 11 months ago

btw. 848x480 also works, despite it was not listed in the device modes, initially (in /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes) But if I set it on the kernel line, I only see modes 848x480 and 640x480.

I installed xorg fbdev and used -retro as parameter, which shows the cursor exactly in the middle and the raster has interferences, I see 48 "waves" so it's exactly the difference between 800 and 848, or a 848 image on an 800 raster. using fbi -vt 1 image.jpg I can show images directly in the framebuffer.

For KlipperScreen it's better to use Xorg :0 and other methods, e.g. graphicsmagick.

Now using the standard armbian again (because it's already fully configured). The following is also valid for your images.

One of these lines works for me:

extraargs=video=HDMI-A-1:e
extraargs=video=HDMI-A-1:848x480e
extraargs=video=HDMI-A-1:640x480e

where the first one is really 1024x768.

Note, my LCD scales automatically (not sure if it once didn't for 640, but this might have been a wrong conclusion) and the touch is always correct ifg KlipperScreen is shown fullscreen.

With 640 text is a bit wider, e.g in the armbian logo (not sure what happens, when it would make buttons bigger, would the touch still work?). 848 is nearer to the intended size. 1024 also works, but lines tend to look a bit more blurry. However you get more characters in the linux console, fairly unsharp but still readable. So I can choose, what looks or works better.

It does not look like the modes, I can set, come from the hdmi device, may be it's some vga or framebuffer logic.

Thanks for this thread, it put me on the right track...

gensoloone commented 11 months ago

I installed Arabian-unofficial_24.2.0-trunk_Mkspi_jammy_edge_6.6.7, logged in for the first time via SSH as root, changed passwords. I didn't make any other settings. I rebooted it. After downloading Arabian, I disconnected the HDMI cable and reconnected it. An image appeared on the display. (Video of this action). A question arose. Is it possible to somehow programmatically, after starting the system, reset the HDMI connection, or restart any service. (Please don't scold me too much for ignorance, Linux is new to me).

Установил Armbian-unofficial_24.2.0-trunk_Mkspi_jammy_edge_6.6.7, первый раз вошёл через SSH под root, пароли сменил. Больше никаких настроек не делал. Перезагрузил. После загрузки Armbian , отсоединил кабель HDMI и подключил заново. На дисплее появилось изображение. (Видео данного действия). Возник вопрос. Может можно ли как-нибудь программно, после запуска системы, реализовать сброс подключения по HDMI, или перезагрузить какой-либо сервис. (Прошу особо не ругать за незнания, Linux для меня в новинку).

hg42 commented 11 months ago

look at my message just above your's. Edit /boot/armbianEnv.txt and add one of the extraargs lines. You probably need to select the output (default is usually another one, e.g. DVI-1 or LVDS-1, etc.) and also add the "e" at the end which "enables" the hdmi output (mine was disabled, otherwise I think it doesn't hurt to enable it a second time). I would first use the first line without a resolution, this should work somehow. Then choose another resolution and see if it works (obviously start with the native resolution, but it will not always work). If the display does not fit the contents (that is scaling in case of a non-native resolution), it get's more complicated (see the thread above), because the touch interface doesn't match the display.

redrathnure commented 10 months ago

OK, my curiosity got the best of me. The MKS IPS50 is on my desk and is waiting for a proper fix.

A few observations after a few experiments:

  1. It works with Windows 10 as well as with standard Ubuntu server. The both current 5.15.0-91-generic and newest 6.6.8-060608-generic kernels work just fine. My conclusion is that hardware itself is fine and problem with kernel or/and Armbian patches.
  2. Ubuntu server is able to read EDID section and explicitly reports "No standard resolution were found". Most likely we need proper patches to add new non standard mode into Armbian kernel.
  3. MKS somehow manage to make it working. According to change log it was done via kernel patching. No open sources as usually. (hello for GPL advocates :) )

To be continue...

hg42 commented 10 months ago

exactly...

However, armbian-mkspi has the unusual mode I need (800x480, it's a cheap 7" aliexpress LCD), but it's still not working that way. With another resolution it worked (the display is scaling somehow), but it's not the native resolution.

redrathnure commented 10 months ago

Somebody reported that it works with 5.x kernel. Plus we have touch pad related issues with the latest 6.6 one. So I have feeling that build based on "old kernel" would be optimal solution from the functionality and stability point of view...

redrathnure commented 10 months ago

I have a good news in new year:)

I managed to make MKS IPS50 screen working with native resolution and without any extra configurations. Please check 0.3.1-24.2.0-trunk release (which will be fully published tomorrow).

@hg42 please check you 7inch 800x480 screen too. Just curious how they are creative and how many custom patches do we need more.

BTW, there are few observations from my side:

  1. MKS IPS50 hardware not so bad, especially for this price. Especially nice is touch screen (in contrast of TS35 one).
  2. However I am not sure does the upgrade worth to be done because a) usually I use laptop or smartphone to work with Klipper and b) small and flexibleTS35 cable should be replaced by two Quite massive cables (HDMI + USB), which must be connected from left side and as result eat too match space.

CC @hg42 , @gensoloone, @goodwin , @NexGen-3D-Printing and @EmJay276

hg42 commented 10 months ago

I wish everyone a happy new year...

I just testet

Armbian-unofficial_24.2.0-trunk_Mkspi_bookworm_edge_6.6.9.img.xz

it didn't change for me:

the native resolution still doesn't show contents on the screen and does an on/off loop or reinitializes continuously: extraargs=video=HDMI-A-1:800x480e

The default resolution (=1024x768) works: extraargs=video=HDMI-A-1:e

And the slightly higher resolution also works: extraargs=video=HDMI-A-1:848x480e

redrathnure commented 10 months ago

Hm.. it's strange. @hg42 have you tried MKS IPS50 or cheap 7" aliexpress LCD one? I would recommend to disable any extraargs=video... args, reboot and then share output of cat /sys/class/drm/card1-HDMI-A-1/edid | parse-edid command (perhaps you need to sudo apt install read-edid before`).

BTW, out of ls /sys/class/drm/ is differ from image to image in my case. Sometimes it's card0-HDMI-A-1 but sometimes card1-HDMI-A-1. Not sure why.

redrathnure commented 10 months ago

BTW, just in case I double checked Armbian-unofficial_24.2.0-trunk_Mkspi_bookworm_edge_6.6.9.img.xz:

hg42 commented 10 months ago

it's a cheap 7" aliexpress LCD

I'm currently on the standard armbian image.

There I get

% cat /sys/class/drm/card0-HDMI-A-1/modes             
848x480
640x480

and the edid file is zero sized, so I get

% cat /sys/class/drm/card0-HDMI-A-1/edid | decode-edid
EDID EEPROM not found.  Please make sure that the eeprom module is loaded.

to test that on the mkspi image I need make console access work. For some unknown reason wifi don't like to work (with the first run configured, and I don't remember what I did to the armbian image to make it work, I should document such things). I guess, a longer LAN cable is my easiest option (right now all my LAN cables are too short).

hg42 commented 10 months ago

ok, I used a cable with diagonal crossing the room...

root@mkspi:~# cat /sys/class/drm/card1-HDMI-A-1/modes
800x480
640x480
640x480
640x480
640x480
720x400
root@mkspi:~# ls -l /sys/class/drm/card1-HDMI-A-1/edid
-r--r--r-- 1 root root 0 Jan  3 15:07 /sys/class/drm/card1-HDMI-A-1/edid
root@mkspi:~# cat /sys/class/drm/card1-HDMI-A-1/edid | decode-edid 
EDID EEPROM not found.  Please make sure that the eeprom module is loaded.
hg42 commented 10 months ago

well, something is different than before.

I think, if I don't use a video= line, the output is not selected. But if I switch the power of the display off and on again, I get the 800x480 viedo mode (as reported by fbset)

mkspi:~:# fbset                   

mode "800x480"
    geometry 800 480 800 480 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,0/0
endmode

so this is a significant progress.

Now I wonder, why those video lines did not work like expected? I also wonder what the "e" does? is it only selecting the second output instead of the default one, or does it initialize the port in some way?

to repeat my former findings, that's how I commented it in the file:

#works:
#extraargs=video=HDMI-A-1:848x480e

#works, default resolution (1024x...):
#extraargs=video=HDMI-A-1:e

#no screen, kind of on/off loop, or reinitializing:
#extraargs=video=HDMI-A-1:800x480e

the first two are expected.

But I would expect the 800x480 line to work, when the resolution exists.

Is there another way to switch (or enable?) the video output?

hg42 commented 10 months ago

unfortunately, for an unknown reason, networking no more likes to work, even with LAN cable... not sure what I do next. So, here are the intermediate results:

the most interesting observation is:

If I use the video line with "e" and no resolution, the display just works in 1024x768. If I use 640x480 or 848x480 (and probably also 1024x768), it works the same. If I don't use a video line, I need to switch the display power off and on, then it shows 800x480 as it should. After switching the power of the display off and on it shows the same resolution without problems.

But if I use 800x480 or 800x480@60, the display does not even work after switching it off and on. Instead after off/on it shows a black and white pattern that fades away and then a message box "No Support" (similar to the "No Signal" box) for some seconds and then goes to the on/off loop. After boot it goes directly to the on/off loop (but the initial screen is dark anyways, probably because another output is enabled).

Sometimes, I see a red screen flashing (maybe only in the boot process?) or some old scrambled screen contents... it looks a bit like the resolution works for a moment, but maybe the timing is not what it wants.

I wonder how it can be a difference between boot and switching off/on.

hg42 commented 10 months ago

note I edited the last message, because the behavior on boot is different like after off/on.

hg42 commented 10 months ago

network/console is back...

if I use the 800x480 video line, I get only these modes:

mkspi:~:# cat /sys/class/drm/card1-HDMI-A-1/modes
800x480
640x480

ok, that's like the standard armbian with a video line. But with mkspi it's the correct mode. Seems like the 640x480 is kind of fallback.

redrathnure commented 10 months ago

@hg42 let's try to slice it step by step....

  1. Network: the image has working LAN and WLAN networking, I just double checked it. However if you use "armbian_first_run.txt" file to connect to the WLAN automatically. it will not work. Seems they disable this feature in latest releases. Which means to install fresh image you have to have worked display or COM/serial connection. 1.1. For the first run it has sense to use standard monitor, just to pass initial wizard with passwords and WLAN/LAN connections. 1.2. However I found more useful to use USB-serial connection. You may try to connect Type-C output on board with laptop and use e.g. Putty client to connect to the find COM port. It's extremely useful because you have console access on every stage (even during initial kernel loading phase) and even if you WLAN or HDMI does not works. PuttySettings WindowsComSettings
hg42 commented 10 months ago

if I only use video=LVDS-1:d (but no video line for HDMI) to disable the first output (hoping the second is the default), I get different modes:

mkspi:~:# cat /sys/class/drm/card1-HDMI-A-1/modes
640x480

but still:

mkspi:~:# fbset

mode "800x480"
    geometry 800 480 800 480 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,0/0
endmode
redrathnure commented 10 months ago

Then about HDMI EDIT and related fun. As far as I understand, by default there are three main point should work out of the box:

  1. OS tracks connected screens. Means it's able to recognize already connected HDMI screen/cable or/and events when you connect/disconnect it to the board.
  2. Each screen must (by specification) support at least 640x480@60 and one of 720x480@60 (NTSC) or 720x576@50 (PAL) resolutions.
  3. Each monitor has internal memory which contains information about "non standard" resolutions which are supported by it. Sometimes it's called EDID or EDID Firmware. And normally OS download this data from monitor via HDMI cable and use it configure related video out (end for example to show supported video resolutions for the monitor in Windows or Linux DM). But! All these works if a) vendor implement specs fully and !!!correctly!!! and b) OS able to access these EDID Firmware.

Now most interested part about MKSPI and HDMI displays, it looks like:

  1. our Kernel unable to access EDID Firmware. Because a) you may try to install normal Ubuntu (e.g. run from Live CD/USB) and connect screen to laptop. Most likley everything will be fine (cat /sys/class/drm/card1-HDMI-A-1/edid | decode-edid or sudo get-edid | parse-edid should work without any issues). Plus there are messages that these screens works with RPi by default. I am not sure what is the right way to fix it, but intuition said following: 1.1. make communication between board-screen work. But I have no idea how to do this. 1.2. hardcode requered HDMI modes in to kernel (e.g. see this commit). Most likely this is not right approach, but seems it works (if we know right EDID mode params). I use regular Ubuntu on my laptop together with sudo get-edid | parse-edid to get needed EDID information for MKS IPS50 screen.
  2. OS must correctly identify connected screens. At least if it was connected before kernel init/OS boot. Seems it does not works for your case. You may use for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done command to realize status of connected screens.
  3. In theory it should be possible to configure HDMI modes via kernel parameters (video=HDMI... extrargs)... however for me it was totally failed. I tried to use recommendations from https://wiki.archlinux.org/title/Kernel_mode_setting#Forcing_modes_and_EDID and http://blog.machinekit.io/2013/06/force-beaglebone-black-hdmi-resolution.html pages, but nothing works for MKS PI image. I am not sure why.