EVOO - Display issues, touchscreen issues, stylus issues on a Gemini Lake (N4000) CPU and DSI internal display

[ralphwig]

Hello. I have a budget 2-in-1 Windows 10 tablet from EVOO (Walmart brand). Model is EV-T2in1-101-2. This is a 10.1 in Windows 10 tablet with

• Intel Celeron N4000 CPU
• 1280x800 touch screen
• Windows Ink stylus support
• 4GB RAM
• 32GB eMMC
• microUSB host port, micro HDMI, headphone jack
• detachable keyboard with fingerprint sensor and USB 2.0 port

It was a decent package, though very low quality, for about $80.

Windows 10 works fine.

Using latest brunch (20200614) and octopus R83, as well as previous brunch and R81 for octopus and rammus. Issue starts at the beginning on boot where the screen is rotate 90 degrees. This can be fixed by passing a "fbcon=rotate:1" in the boot parameters. Once the GUI loads, it is horribly messed up. There's a large black line running across horizontally, the corners are all messed up, and the color channels look incorrect, as well as the image is flipped across the x-axis (mirrored). This stays long enough to cause burn in damage for a lengthy period of time. Video out via micro HDMI works great and everything else seems to run fine, except for the stylus. Touchscreen does seem to function but touch points are not synced with the screen rotation, fingerprint probably not (didn't see if there's even an option for it yet).

This is the same issue with the latest Ubuntu Desktop (20.04 LTS) that I loaded over USB as well. There, I played with my limited knowledge of Linux video (all my knowledge is from looking up this and similar issues in search) and tried xrandr but had no luck. With a combination of some changes and closing the lid and reopening, the horizontal lines did seem to go away, but all the The stylus

Issue might be related directly to the i915 Intel video driver and the Intel Celeron N4000 CPU / Intel UHD Graphics 600 ("Gemini Lake") and an internal MIPI DSI display.

Similar issue I found regarding Gemini Lake and DSI display from Lenovo D330, notably the one with the same 10.1 inch 1280x800 screen (AUO17D8): https://bugs.freedesktop.org/show_bug.cgi?id=108826 https://bugs.freedesktop.org/show_bug.cgi?id=109267

And it seems like it was fixed at some point in the i915 driver?

Other brunch related issues that may also be relevant, especially regarding the same Lenovo D330 model and similar bargain bin tablet: https://github.com/sebanc/brunch/issues/276 https://github.com/sebanc/brunch/issues/122

EDIT: While putting this together, I ran ChromeOS with the kernel parameter drm.debug=0x1e as mentioned in the links above, which I thought was to get more verbose debug information, and what do you know? The display is perfect! Still issues with touchscreen not mapping correctly (not rotating properly with the image, so a touch on the top-left is actually, visually, a touch on the bottom-right. Also stylus does not work.

[sebanc]

Hi, the fixes related to the bugs you refer to are already included in the brunch kernel. I think all those issues might be related to the screen orientation which I have recently fixed for Lenovo D330 in brunch kernel.

I can try to do the same for your device but I would need: 1) A dmesg (run "dmesg > ~/Downloads/dmesg.txt" in crosh shell and attach dmesg.txt from your Downloads folder) 2) The output of the below commands: cat /sys/class/dmi/id/product_name cat /sys/class/dmi/id/sys_vendor

[ralphwig]

Thanks. Here's the dmesg I ran, but it includes the drm.debug option, so it may have extra lines. Let me know if it's too much.

Product Name: EV-T2in1-101-2 Sys Vendor: EVOO Products Company, LLC.

Just to add to my video issues, I'm not entirely sure what's going on, but as is, there are still times the screen boots weird, sometimes fixed by sleeping/waking the screen, but before adding in drm.debug = 0x1e, it would never work correctly. Ubuntu 20.04 live still doesn't work properly. I also attached the pics of the various video issues so others can see and may have similar issues.

dmesg.drm.debug.txt

[sebanc]

You mention 1280x800 touch screen but the display reports resolutions up to 1920x1080. What's the native display resolution in windows ?

[ralphwig]

Oops, that's over HDMI since I had HDMI plugged in as well. The internal display is DSI and 1280x800 max. Here are two new dmesg without HDMI attached. One with drm.debug and one without.

dmesg.drm.debug-2.txt dmesg-2.txt

Also 2 images to again show the video issues: first shell without drm.debug, the second is shell with drm.debug but you can see the burn-in/retention on the dark screen (edges and bar across the middle) from the messed up screen still..it will eventually go away.

[sebanc]

Could you try booting with "video=1280x800-32" added to the kernel command line and see if it helps with the display issue (and also try "video=800x1280-32" if it does not work) ?

[ralphwig]

Both video commands have the same problem as not putting anything. I have tried other similar kernel options such as "video=inteldrmfb:800x1280-32@60" that I found to try elsewhere and I also tried using the display EDID recognized and used by Windows and loading it with the kernel (I copied it to the kernel partition 7). Some of what I tried was here to try different video options, like here for Arch Linux: https://wiki.archlinux.org/index.php/Kernel_mode_setting

I don't really know too well what I'm doing with kernel and drivers in Linux, but I've tried what I could find.

[sebanc]

Could you try the test build there: https://github.com/sebanc/brunch-testing/releases

I applied the same patch as for Lenovo D330 which should put the screen in the correct orientation at boot without using "fbcon=rotate:1" and potentially fix other issues.

[ralphwig]

Ok, I updated the brunch through the shell with the testing release. I booted without drm.debug. It booted with the same video issues, but after a few sleep/wake of the screen it was working! The screen was stil rotated, so I went to Settings and set it to 0 degrees (from the 270 degree I had set before) , and it was still rotated upside down so I set it to 180 degrees now. Touch is still rotated 180 degrees to my display orientation.

new dmesg and image attached: dmesg_testing_kernel.txt

[sebanc]

Could you try adding "video=800x1280-24" to the kernel command line ? Do you have a display while booting ? Is the screen rotated 180° directly on boot (that would be normal for now) ?

[sebanc]

I tried another patch in the new test build: https://github.com/sebanc/brunch-testing/releases

[ralphwig]

Will try the new test shortly. The video=800x1280-24 had the same results. I do have a display while booting. It is 90 degrees counter clockwise. fbcon=rotate:1 rotates that portion back. On load of Chrome OS, when the screen is functioning correctly, which is very uncommon, the screen is now 180 degrees rotated. I haven't tried the latest test kernel yet and will report back

[ralphwig]

New test kernel has the same results. I made a new brunch with test kernel 0623 and R83 rammus and had same results as well. Command line loading is 90 degrees counter clockwise and with the test kernel, Chrome OS video display is 180 degrees rotated, but touch is not rotated, so out of sync by 180 degrees. Rotating in Chrome OS rotates both the display to correct and then the touch to 180 degrees the other way so still out of sync by 180 degrees.

Other observations:

• fbcon=rotate:1 only has an effect on the preloading loading script text. Once ChromeOS loads, it doesn't respect that setting
• drm.debug=0x1e is still the best way to get proper video displaying, but probably as a side effect. I remember seeing something about the timing being an issue with Gemini Lake and DSI with the video driver, and maybe the added delay might help things work properly

And regarding the video issues that come up, there seem to be 4 kinds I've noticed:

1. horizontal bar across the middle and glitchy looking like the signaling is off
2. horizontal bar across the middle and video looks not glitchy, but looks flipped both x-axis and y-axis and color channels are crossed
3. no horizontal bar and not glitchy, but flipped on both x-axis and y-axis and color channels are crossed
4. regular image

Without drm.debug option, sometimes sleeping/waking would go through different types mentioned, very rarely ended up on 4, usually stuck at 2 or 3. With drm.debug option, it's usually 4, rarely 2 or 3.

[sebanc]

Sorry but I am not sure I correctly understand the test results:

• Did you see any change between the first brunch release you have installed and the first test build ?
• Did you see any change between the first test build and the second one ?

[ralphwig]

Hi. I will try to summarize the outcome of the various tests.

In all scenarios, screen still has issues not displaying properly (glitchy, x and y flipped, colors crossed, black bar as mentioned in my previous post). Nothing has prevented that so far in the different kernels. The only thing that has helped consistently with that problem is adding kernel parameter" drm.debug=0x1e", which resolves the messed up display 90% of the time.

The tests results below are when the display is functioning properly, as there is still screen rotation and out of sync touch in each scenario, as well.

Test 0 was current brunch release (20200614) with R83 octopus. Screen was rotated 90 degrees counter clockwise, I believe. Touch is opposite 180 degrees.

Test 1 was testing kernel 1 (20200621) upgraded in same R83 octopus. This was mostly the same, but screen was rotated 180 degrees now. Touch is opposite 180 degrees.

Test 2 was testing kernel 2 (20200623) with a new brunch install R83 rammus. Same issues as test 1 and screen is still 180 degrees. No observable difference in regards to screen issues between test 1 and test 2.

So two levels of problems, one is the screen not working properly, which may be related directly to the N4000 CPU part and the 1280x800 DSI screen, but drm.debug provides some relief from that major problem. Two is the configuration of the screen and touch rotation, if that is something that can be fixed.

Other issues originally mentioned involve Stylus support not working, though dmesg does seem to identify a Pen device, and another unmentioned issue is rotation. BIOS had an option for Intel sensor hub which is now enabled (default was disabled) and also showed in the latest dmesg but failed to load.

Thanks for your help in trying to resolve these issues.

[sebanc]

Ok, that's a bit weird for me right now as Test1 and Test2 should not give the same results as I completely changed the patch. I was expecting Test2 to either behave like Test0 or like Test1 with opposite 90° rotation... I will try to review the patch I applied but for now it is very confusing.

[sebanc]

I added debug prints in the below release, could you install it and post a new dmesg ? (without "fbcon=rotate:1" but you can keep "drm.debug=0x1e") https://github.com/sebanc/brunch-testing/releases

[ralphwig]

I updated the kernel to the latest test (20200625). I used drm.debug=0x1e option boot.

Booting command line was rotated 180 degrees.

When booted to ChromeOS, at 0 degree rotation in Settings, it was 90 degrees clockwise. Changing settings to 270 degrees straightens it out. This is the same rotation in ChromeOS as the current non-testing kernel (20200614). Touch is still 180 opposite.

Attached dmesg and screenshots: dmesg_test_kernel_0625.txt

[sebanc]

Could you try the new test build ? (without "fbcon=rotate:1" but you can keep "drm.debug=0x1e")

[ralphwig]

Here are the results with testing kernel 20200628, still using drm.debug

• booting command line is rotated correctly
• Chrome OS is still rotated 90 degrees clockwise
• touch is still reversed (180 rotation from the current screen orientation)

Attached dmesg and pics.

dmesg_testing_0628_2.txt

Thanks

[sebanc]

Ok, so it confirms that modifying the console rotation has no impact on the touchscreen...

Could you try the new testing release ? (the console will be rotated as initially but I expect the ui display rotation to match the touchscreen)

[ralphwig]

Results with testing 20200630:

• console rotated 90 degrees counter clockwise, which is how it was initially as you said
• Chrome OS is rotated 90 degrees counter clockwise as well now
• touch is still opposite orientation (180 degrees) of the dsiplay orientation

New dmesg and image attached dmesg_testing_0630.txt

[sebanc]

Ok so it seems the kernel changes I make always affect both the display and touchscreen. When you use "fbcon=rotate:1" is the touchscreen mapping rotated 180° or 90° ?

[ralphwig]

fbcon=rotate:1 doesn't to have any affect on the ChromeOS side of things, it seems only rotates the console on boot. Touch is still opposite (180 degree rotated) of whatever ChromeOS is showing on my display. So tapping on the top left will be a tap registering on the bottom right. Rotating the display in settings will also rotate the touch, so it will still be 180 degree opposite.

[sebanc]

Could you run "sudo nano /etc/gesture/80-inverted_touchscreen.conf", copy the below content in nano, save and reboot ?

Section "InputClass"
    Identifier      "Evdev for Inverted TouchScreen"
    MatchProduct    "GXTP7386:00 27C6:0113"
    MatchDevicePath "/dev/input/event*"
    Driver          "evdev"
    Option          "InvertY"         "1"
    Option          "InvertX"         "1"
EndSection

[ralphwig]

Sorry for the late reply. I tried the conf file as you had it and and it didn't have any effect. I also tried a few variations I found online using transformation matrix and applying to all touchscreen devices rather that specific one, and nothing. I'll attach the dmesg a but later, but I couldn't see whether it even loaded the conf file in the dmesg in any scenario.