chromebook_kukui: status: krane (lenovo chromebook duet 10.1)

Question

chromebook_kukui: status: krane (lenovo chromebook duet 10.1)

Opened this issue 2 years ago · 44 comments

hexdump0815 commented 2 years ago

Notes on krane running 5.18.1 - for updated information please have a look at this comment below: #53 (comment):

Here is list of working and non working features on the lenovo chromebook duet 10.1 (krane).

Working

wifi
bluetooth
builtin display
energy: battery status, dpms, suspend/resume
usb c for basic usb functionality
gpu opengl: via mesa panfrost (opengl 3.1)
sound: speaker works, internal mic works with verly low levels

untested

hw video encode/decode: most probably not working yet

broken

webcams: not working yet, unclear if they can be made working as they are just simple cameras and no usb video class cameras like on other chromebooks
external display: not working yet

Installation

coming soon

PROBLEMS

none so far

Answer 1 · 2023-06-01T18:13:21.000Z

Is this https://github.com/hexdump0815/imagebuilder/blob/main/doc/install-to-emmc-on-arm-chromebooks.md a correct way of installing to emmc on ideapad duet 1.gen 4GB/128GB?

Answer 2 · 2023-06-02T22:15:49.000Z

yes - that should be the correct way

Answer 3 · 2023-12-02T12:28:56.000Z

@hexdump0815 I have some updated status based on a more recent kernel + userspace combination, it would be great if you can update the issue description with these. I think GNOME's tablet-style UI works pretty well on this device, so I've replaced xfce with it. It's still a little sluggish but it's somewhat tolerable.

Software setup

kernel: 6.5.5
distro: Debian sid
mesa: 23.2.1 (from the Debian sid repo)
window protocol: wayland
desktop environment: gnome

Working

Wi-Fi (including WPA3-SAE and 802.11w) and Bluetooth
Built-in display (orientation, brightness controls)
Energy: battery status, dpms, suspend/resume
IIO sensors: ambient light sensor (auto brightness), accelerometer (untested), gyroscope (auto-screen orientation, udev rule required)
Trackpad: works well, libinput quirk required to configure pressure correctly. Quirks have been submitted to upstream.
USB: basic USB host and charging only
Touchscreen: works out of the box, orientation is correct and follows screen rotation on GNOME
Graphics: OpenGL works out of the box with panfrost, zero screen tearing with wayland.
Audio: speakers work fine

Needs work

Will investigate in these when I have more time.

Hardware video decoding/encoding: firmware is loaded but userspace support is missing. Need to test if v4l2-request works at all on this platform.
Pen digitizer: axes are swapped, needs an accel matrix config. Pen pressure works but registers a touch before the pen touches the screen, needs a way to add an offset before it's usable.

Broken

Audio: internal microphones are extremely quiet and completely unusable
Cameras: CSI cameras, no mainline support, patches were sent but abandoned
USB-C display output: the ec fails to configure the USB-C port with the following error message: No valid DP mode provided.

Notes

IIO sensors require iio-sensor-proxy to be installed and running for them to work with GNOME.
Hardware compositing needs to be manually enabled on both Firefox and Chromium. I have only tested wayland so there are no x11 instructions unfortunately.

Make sure both Firefox and Chromium are running in wayland by setting the environment variable MOZ_ENABLE_WAYLAND=1 for Firefox, and set the flag ozone-platform-hint to auto for Chromium. Additionally, you need to set gfx.webrender.all to true in Firefox. After that, you can verify hardware acceleration at about:support in Firefox and chrome://gpu in Chromium.

Unfortunately I have observed increased system freezes when browsers are using hardware accelerated graphics, but it does make web browsing a lot more tolerable on this device.

Answer 4 · 2023-12-02T20:03:25.000Z

@vulpes2 - thanks a lot for the feedback - i have linked your comment in the issue description ... in case you find out anything about the still open topics, please followup here ... btw. fyi: i gave v6.6 recently a try and found a few regressions: hexdump0815/linux-mainline-mediatek-mt81xx-kernel@6a3ca0b - i did not find solutions for them yet

Answer 5 · 2023-12-03T10:50:57.000Z

I haven't had time to check out kernel 6.6 yet, but I did try to fix the digitizer with some level of success. The pressure range is now correct but rotation still doesn't work yet. Once I figure that out I'll send the quirks to libinput so we don't have to deal with downstream configs anymore. The udev rules can't be submitted to systemd because they're too generic, I'll have to make it more specific to the device before sending them to systemd .

Answer 6 · 2023-12-03T15:32:43.000Z

I was unable to get digitizer rotation to work properly, but at least it works properly in one single orientation now, which is better than nothing I guess.

Here's the libwacom config that makes the digitizer configurable with gnome-control-center or kcm-wacomtablet. Add the file as /etc/libwacom/google-krane.tablet and then run libwacom-update-db, the digitizer should show up in the GUI tools afterwards. Ideally there should be a custom stylus entry that specifies zero buttons, but that can come at a later date.

[Device]
Name=hid-over-i2c 27C6:0E30 Stylus
ModelName=
DeviceMatch=i2c:27c6:0e30
Class=ISDV4
Width=5.35433
Height=8.54331
IntegratedIn=Display;System
Styli=@generic-no-eraser

[Features]
Stylus=true
Touch=false

This is the libinput quirks file that fixes the trackpad and pen digitizer pressure range, place at /etc/libinput/local-overrides.quirks and reboot. This will at least make the digitizer usable, tested with xournal++ and it seems to work pretty well.

[Google Chromebook Krane Trackpad]
MatchUdevType=touchpad
MatchName=Google Inc. Hammer
MatchBus=usb
MatchDeviceTree=*krane*
ModelChromebook=1
AttrPressureRange=20:10

[Google Chromebook Krane Stylus Digitizer]
MatchUdevType=tablet
MatchDeviceTree=*krane*
MatchBus=i2c
ModelChromebook=1
AttrPressureRange=1100:1000

Answer 7 · 2023-12-09T08:30:17.000Z

Tested v6.6 with your configs on krane and nothing seems horribly broken so far compared to v6.5. The high pitched noise was still a problem as of v6.5. I made a small change to the dt on top of your patches, let's see if that will help with the problem. This is pretty hard to reproduce deliberately, so only time will tell if it actually works or not.

Edit: the added delay does not help at all, root cause is somewhere else.

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-max98357a.dtsi b/arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-max98357a.dtsi
index 2b60967c0c1c..32d0dc63bf5d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-max98357a.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-audio-max98357a.dtsi
@@ -9,5 +9,6 @@ / {
        max98357a: max98357a {
                compatible = "maxim,max98357a";
                sdmode-gpios = <&pio 175 0>;
+               sdmode-delay = <2>;
        };
 };

Answer 8 · 2023-12-10T20:41:20.000Z

Hi there,

Piggy-backing on this discussion as I just installed 230917-01 ubuntu jammy on my Lenovo IdeaPad Duet Chromebook 10.1 (MT8183), running GNOME 42.9 (alternating between Xorg and Wayland) and kernel version 6.1.51-stb-mt8+.

@vulpes2, your instructions above worked beautifully on my system with Lenovo USI pen! Tested by doodling in inkscape and krita. The latter one amazed me: I thought this USI pen was defect as it never worked properly on Chrome OS, but with Krita is works so incredibly well, it's an absolute pleasure to draw!

Other than that, the system seems to run as one would generally expect (comparing with other computers I own with Intel processors running different versions of Ubuntu and Debian), no major disasters so far. Hardware acceleration works as described above, tested with firefox and youtube videos (huge difference).

Broken

Internal mic very quiet as reported above
Webcam is not detected
No screen lock after waking up despite being enabled (probably fixable: did not try to troubleshoot)
Screen rotation is doing weird things (all on GNOME):
- With Xorg, the screen is rotated at login, to put it in the correct orientation I use xrandr -o left. Then when I turn it into either of the two possible portrait modes, I need to use either xrandr -o normal or xrandr -o inverted. If I flip it upside-down in landscape mode, then it's xrandr -o right. My temporary workaround is getting it into the desired orientation and locking screen rotation.
- On Wayland it starts normally when logging in default orientation (i.e., landscape), but screen rotation does not seem to work. After waking up from sleep the sound some sometimes messed up. Manually locking the screen and then unlocking it rotates the screen rotates the screen to portrait mode, which is restored be sending the computer to sleep and waking it up.

Do you think upgrading to kernel 6.5 or 6.6 would fix the screen rotation issue?

Answer 9 · 2023-12-10T21:52:29.000Z

Thank you for the feedback, I was particularly interested in the USI pen because I was not 100% sure if it was just my USI pen or digitizer being weird or not. Given it's not a defect on my device, I will be able to send these quirks to libinput now.

Manually locking the screen and then unlocking it rotates the screen rotates the screen to portrait mode.

By default the sensor orientation is 90 degrees off. Please make sure you have added this udev rule mentioned above to correct the sensor mount orientation. Keep in mind that even if auto-rotation is disabled on GNOME when the device is not in tablet mode (keyboard folded to the back or detached), it will still auto-rotate your screen to the default/upright orientation according to the sensor when the machine is woken up with the keyboard attached, which is why you're seeing an incorrectly rotated screen after waking up the device from standby. The udev rule will address that and all the orientation issues should be gone after you add it, I don't think upgrading the kernel is necessary.

Answer 10 · 2023-12-11T00:31:59.000Z

Thank you for explaining! Adding that udev rule has indeed fixed the rotation issue.

auto-rotation is disabled on GNOME when the device is not in tablet mode

Ah, tablet mode! What confused me was Xorg, it was rotating the screen regardless of the keyboard position, I thought that was the expected behavior. Now it all makes a lot of sense. With the orientation being fixed, Gnome on Wayland behaves as a laptop with the keyboard attached and "unfolded", and as a tablet when the keyboard is detached or folded to the back.

Thank you for the feedback, I was particularly interested in the USI pen because I was not 100% sure if it was just my USI pen or digitizer being weird or not. Given it's not a defect on my device, I will be able to send these quirks to libinput now.

Happy if I can help! Anything else I should test?

Answer 11 · 2023-12-11T05:27:42.000Z

i just wanted to say that i'm very happy to see some activities like this here, i.e. extending the functionality of the images and sending fixes back upstream (like for libinput in the above case) ... my idea with the images was to make it easier to get started on certain hardware (like chromebooks in this case) as in the past it was always quite painful to get normal linux running on them (booting, partitioning, quirks etc.) ... in case you have anything we can bring into future images i'm happy to merge pull requests adding extra config files etc. via systems/chromebook_kukui/extra-files (in case the changes are not of a generic nature it might still be possible to bring them in as file.sample or commented out), also adding extra config and setup info via systems/chromebook_kukui/doc/some-file.md might be a good option once everything has settled around how to do certain things.

Answer 12 · 2023-12-11T21:37:12.000Z

@hexdump0815 I've opened a few pull requests to do some basic cleanup but most of these aren't specific to krane.

The libinput quirks for krane and wormdingler will be submitted to libinput very soon, but the udev rule will probably have to remain downstream for now since udev doesn't seem to be able to apply dt based filtering with hwdb like libinput can with the quirks database, so if you don't have ACPI it seems to be all-or-nothing unfortunately. On top of that, the udev rule from the pmos wiki seems to be a hack too, I found out that the property was applied to every single input event devices on the system, which doesn't necessary break anything but probably still not a good practice nonetheless.

@janamach If you're on GNOME you may encounter this bug too, where the touchscreen will become unresponsive and appear frozen until you press Esc on a physical keyboard. It's reportedly fixed in 45 but I don't know if that will be backported to older releases: https://gitlab.gnome.org/GNOME/mutter/-/issues/3181

Answer 13 · 2023-12-11T23:17:43.000Z

@hexdump0815 I really appreciate your initiative with the images! At this point I still lack a lot of knowledge for being able to port a device myself, so I admire those who can. This said, I now own a super awesome tablet all thanks to your project. Thank you :)

@vulpes2 I have not encountered that bug specifically yet, but I've observed the following weirdness on GNOME:

Connecting a monitor through HDMI->USB-c disables touchpad and physical keyboard. The functionality is restored after reboot. The monitor is detected by the tablet, but not the other way around, so there is no actual HDMI output, but tablet thinks there is. So there are two bugs in one :)
I have observed GNOME randomly refusing to revert to desktop mode after being used in tablet mode. This is fixed by closing the lid (or sending to sleep) for a moment.

What works consistently is the USI pen, I am still amazed. I wanted to trash that thing, it was frustratingly useless on Chrome OS and every web search would lead me to posts of other people complaining. Some said they sent theirs back and received a functional replacement from Lenovo, so I thought mine is just broken (or from a bad batch). But now am convinced it's all software. Weird that Lenovo and Google couldn't get it to work properly, this pen had so much hidden potential.

Answer 14 · 2023-12-12T12:38:03.000Z

The first gen Lenovo USI pen is widely reported to be broken, mine actually drains its battery within a month which is super irritating. USB-C display output is completely broken at the moment, there is a video converter chip in the signal path that doesn't seem to be working properly with mainline kernel (there was a patch to add it to the dt), the exact reason is unknown thus far.

Answer 15 · 2023-12-12T13:29:48.000Z

As I see. External display output is not a big deal for me, I wasn't planning on using it like that anyway.

Not sure if my USI pen drains the battery like that. I did have to replace it a couple of times, I'll keep an eye on it now. The main problem with it was that it was "too sensitive": it would write and click on things while the tip was not touching the screen. IIRC, this distance to the screen when it would start doing things was also not consistent. People reported that different hacks worked for them, e.g., removing the battery for some time and inserting it back in while pressing on the tip, or inserting a spacer ring just above the tip and so on. None of that really worked for me, it was too uncomfortable to use. I also did not find a good use for Chrome OS, so I left the whole thing lying in the corner for months. Until now ;-)

External display output is not a big deal for me, I wasn't planning on using it like that anyway, a linux tablet with a working pen is the thing that was missing in my life :-) Would be nice to have the mic and the cameras working though. Anyone working on those issues?

Answer 16 · 2023-12-12T18:45:15.000Z

@vulpes2 - thanks a lot for the pull requests - they all looked good to me and i already merged them

external display via usb-c never really worked with mainline on kukui as far as i know - the patch floating around seems to only add the corresponding dt pieces from the chromeos kernel, but i think the type-c code in chromeos has some extras needed for that, which are not in mainline ... i'm not sure, but maybe this looks like something getting closer there with mainline: https://patchwork.kernel.org/project/dri-devel/cover/20230331091145.737305-1-treapking@chromium.org/ - i'm not 100% sure and did not play around with it myself yet though

Answer 17 · 2024-03-16T11:14:54.000Z

I was unable to get digitizer rotation to work properly, but at least it works properly in one single orientation now, which is better than nothing I guess.

Here's the libwacom config that makes the digitizer configurable with gnome-control-center or kcm-wacomtablet. Add the file as /etc/libwacom/google-krane.tablet and then run libwacom-update-db, the digitizer should show up in the GUI tools afterwards. Ideally there should be a custom stylus entry that specifies zero buttons, but that can come at a later date.
[Device]
Name=hid-over-i2c 27C6:0E30 Stylus
ModelName=
DeviceMatch=i2c:27c6:0e30
Class=ISDV4
Width=5.35433
Height=8.54331
IntegratedIn=Display;System
Styli=@generic-no-eraser

[Features]
Stylus=true
Touch=false
This is the libinput quirks file that fixes the trackpad and pen digitizer pressure range, place at /etc/libinput/local-overrides.quirks and reboot. This will at least make the digitizer usable, tested with xournal++ and it seems to work pretty well.
[Google Chromebook Krane Trackpad]
MatchUdevType=touchpad
MatchName=Google Inc. Hammer
MatchBus=usb
MatchDeviceTree=*krane*
ModelChromebook=1
AttrPressureRange=20:10

[Google Chromebook Krane Stylus Digitizer]
MatchUdevType=tablet
MatchDeviceTree=*krane*
MatchBus=i2c
ModelChromebook=1
AttrPressureRange=1100:1000

So for this I found a really simple fix.

First you need to identify the Stylus using xinput list After that note down the ID. In my case it was 14. Now paste this command into you're Terminal. xinput set-prop 14 "Coordinate Transformation Matrix" 0 -1 1 1 0 0 0 0 1 Remember to replace 14 with the actual ID of you're Stylus. After that, test. This will make the Stylus usable in the "Tablet Orientation" as well making it much more usable.
But for some reason this change goes away everytime you reboot. So we have to make it automatically run at startup. For this open up a Terminal Window and type in gnome-session-properties. Press Add. Give it a Name you like and in the command Line you type in xinput set-prop 14 "Coordinate Transformation Matrix" 0 -1 1 1 0 0 0 0 1 (Remember to xinput list to find you're device ID) Now save. That's it!

Answer 18 · 2024-04-07T05:39:24.000Z

Hi I am not sure if this is the right place to ask but I recently got a Lenovo Chromebook Duet 10.1 and it came with Ubuntu 22.04 installed by someone. I want to know if there is a way to wipe the Linux system and restore it to Chrome OS? I did some searching but have yet found anything useful. I tried MrChromebox's script but it says ARM64 devices are not supported. Can someone post a link to any guide related to my issue? Thank you very much!

Answer 19 · 2024-04-07T09:40:42.000Z

Follow the instructions here: https://support.google.com/chromebook/answer/1080595?hl=en, ignore the "less invasive steps", start from Recovery option 2: Use USB drive.

Answer 20 · 2024-05-13T18:01:56.000Z

Software setup

kernel: 6.5.5

distro: Debian sid

mesa: 23.2.1 (from the Debian sid repo)

window protocol: wayland

desktop environment: gnome

(truncated from #53 (comment))

Is there any way to get a bootable image of this so that we don't have to try to get all that set up after installing?

Answer 21 · 2024-05-14T13:26:01.000Z

@osfanbuff63 are you looking for this or something else?

https://github.com/hexdump0815/imagebuilder/blob/main/systems%2Fchromebook_kukui%2Freadme.md

Answer 22 · 2024-05-23T12:53:34.000Z

Those still run on XFCE last time I tried, but I'll check it again to make sure

Answer 23 · 2024-06-28T14:26:22.000Z

so i got my hands on duet 10.1
was very cheap for some reason :3
but is have a slight problem with it

i can't seam to be able to set gbb flags for it
i tried unplugging the battery but it doesn't work

anyone know where can i find a write protection screw or sth?
there is no hardware maintenance manual (i could find) so 'm out of ideas

Answer 24 · 2024-06-28T17:08:50.000Z

@LukIsHere - i also ran into this problem that the battery-disconnect option does not seem to work for krane ... you can ccd open it via suzyqable (see: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks) and in case you do not have one (i would really recommend to get/build one if you deal with as many chromebooks as you do now :) ) then maybe search around a bit for "sh1mmer" - with that approach and some modifications i was even able to get linux booted from usb on a krane with dead emmc (and thus no regular way to ccd open it and make it boot from usb due to the battery problem you mentioned) :)

Answer 25 · 2024-06-28T21:25:55.000Z

there is no way i can order one at reasonable price, and building one
o my
it sounds scary and looks even scarier
i've never used resistors in my entire life
can probably order them online but the site says 1% and shop says 5%, i don't want to mess it up so will probably have to visit my local electronics store so ppl there can help me get the right parts
will give it a shot ^~^
Sidenote. i think i managed to get depthcharge tools working but it's producing images at 46mb (kinda over 32mb, it's so bloated :3) so i have to do fresh emmc install to test if these even work

Answer 26 · 2024-06-29T07:54:33.000Z

@LukIsHere - too large images sound like kernel and initrd are not heavily enough compressed - see https:/https://github.com/hexdump0815/imagebuilder/blob/main/doc/install-to-emmc-with-luks-full-disk-encryption.txt#L213-L231 and /github.com/hexdump0815/imagebuilder/blob/main/doc/install-to-emmc-with-luks-full-disk-encryption.txt#L235-L285 - this way it can be made small enough (i.e. < 32m) - no idea if there is a way to teach dethcharge tools this - i did not look into it yet

Answer 27 · 2024-06-29T09:17:44.000Z

lack of compressing is least of my concerns since it doesn't boot
also we should probably move this discussion to a separate issue

Answer 28 · 2024-07-01T14:11:00.000Z

Hi, are we expected to get any new updates for the new Ubuntu releases (23, 24)?

Answer 29 · 2024-07-01T14:41:38.000Z

@tech-with-mo if you need a newer version of ubuntu just update ur /etc/apt/sources.list to ubuntu 23/24 one and run sudo apt update && sudo apt dist-upgrade

Answer 30 · 2024-07-01T20:15:42.000Z

@tech-with-mo - i plan to build newer version, but just do not have the time for it right now - i already added ubuntu noble support to the framework, but found some problems on my first test images which i'll have to sort out first ... what @LukIsHere suggested might work for some setup or not for others (zstd compressed kernel modules in ubuntu noble being the biggest problem - see hexdump0815/kernel-config-options@592147c ) ... newer images will come, its just not clear yet when

Answer 31 · 2024-07-02T14:23:10.000Z

@LukIsHere - i also ran into this problem that the battery-disconnect option does not seem to work for krane ... you can ccd open it via suzyqable (see: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks) and in case you do not have one (i would really recommend to get/build one if you deal with as many chromebooks as you do now :) ) then maybe search around a bit for "sh1mmer" - with that approach and some modifications i was even able to get linux booted from usb on a krane with dead emmc (and thus no regular way to ccd open it and make it boot from usb due to the battery problem you mentioned) :)

i got the suzyqable and manage to disable hardware wp on different chromebook but not this one
the problem with method i am using is that it requires the "pp" button to which i don't have access to since i do not poses the keyboard accessory

is there any workaround/different method for it?

also the ttyUSB* doesn't showup on debian devices only chromeos devices, any way to fix that too?

Answer 32 · 2024-07-02T20:10:04.000Z

@LukIsHere - that was quick for the suzyqable, nice to hear that you got one working - for krane (and tablets in general - i would say in in general for all chromebooks actually even) the pp button is the power button (on the tablet part for krane) - just a quick press is enough usually

ttyUSB* devices should also show up on debian, but will not on kukui devices (and maybe other chromebooks with mainline kernel too) as the usb stack seems to still be a bit buggy for them, at least buggy enough for not working well with the suzyqable ... one thing to also keep in mind is that the orientation in which the suzyqable is plugged into the target device (chromebook to ccd open) matters - it only works in one direction/orientation

good luck and best wishes - hexdump

Answer 33 · 2024-07-18T12:46:46.000Z

@hexdump0815
i tested it
it's bronke on trogdor

acer spin 513
lenovo ideapad duet 5

kukui

lenovo 10e

but works on corsola

lenovo ideapad slim 3

would it be good idea to use the chromebook spin of kelner for kukui/trogdor?

Answer 34 · 2024-07-18T16:40:26.000Z

@LukIsHere - what exactly is broken? (i lost the overview a bit) ... it does not work to use the trogdor kernel for kukui as they still need different sets of patches (trogdor close to none, but kukui need still quite a few) and as put together at the moment also the required dtb files for the other wardware are not included.

Answer 35 · 2024-07-18T16:43:57.000Z

@hexdump0815 it simply doesn't appear when ls /dev/ttyU*
i know it's not cable orientation issue cause i used usb-A cable port (if present, on ideapad slim 3 and acer spin) and it worked on corsola

Answer 36 · 2024-07-20T08:30:00.000Z

@LukIsHere - it could be that the usb stack has a problem on both kukui and trogdor - i remember that kukui was always a bit problematic regarding usb but i never tried trogdor ... what might be worth a try it to give a newer kernel like v6.10 a try on kukui - i did some tests with v6.9 some weeks ago and usb looked a bit better, but sadly the display support was broken on krane (which i tested it on)

Answer 37 · 2024-08-02T16:15:30.000Z

yeah, squable isn't the only thing not working i have also usb cd reader that works only on corsola
but requires sudo modprobe isofs to be run in order to read the files
will give v6.9 a shot when i finish working on waydroid

Answer 38 · 2024-08-05T16:00:08.000Z

6.9 doesn't fix the suzyqcable, 6.10 even breaks usb :3
the device detects something is plugged in

root@chluk:/compile/source/linux-stable-cbq# lsusb 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0bda:5414 Realtek Semiconductor Corp. USB2.1 Hub
Bus 001 Device 003: ID 18d1:5052 Google Inc. Hammer
Bus 001 Device 033: ID 18d1:5014 Google Inc. Cr50
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0bda:0414 Realtek Semiconductor Corp. USB3.2 Hub

but there still is no tty

root@chluk:/compile/source/linux-stable-cbq# ls /dev/ttyU*
ls: nie ma dostępu do '/dev/ttyU*': Nie ma takiego pliku ani katalogu <- no such file or directory

Answer 39 · 2024-08-06T16:59:45.000Z

looks like usb on kukui is not in a good shape right now - i'll have to look deeper into it once i find a bit more time

Answer 40 · 2024-09-24T16:34:55.000Z

Touchpad quirks for krane, wormdingler and coachz have been submitted to libinput. The pen pressure issue is not the fault of the digitizer and cannot be upstreamed, because the Levovo USI Pen is defective. Many people have been experiencing similar issues in ChromeOS as well with this specific pen. Will try to get the digitizer rotation and gyro offset fixed upstream when I have more time.

Answer 41 · 2024-10-06T16:43:35.000Z

Touchpad quirks for krane, wormdingler and coachz have been merged and will be in the next libinput release. There are a few more things that needs to get done, will get to them at some point.

Submit tablet information to libwacom (krane, wormdingler, coachz)
Upstream the ACCEL_MOUNT_MATRIX udev rules (krane, wormdingler, coachz)
Fix pen digitizer rotation and ensure auto-rotate works (krane, wormdingler, coachz)
Upstream UCM config
Look into the mic gain situation for krane, gain setting might be applied in either dt or by a daemon in userspace on ChromeOS (software gain is the canonical solution)

Answer 42 · 2024-10-06T19:36:16.000Z

Looked into the mic gain situation, there is nothing we can tweak in the codec, CRAS is applying a 20db software gain via the IntrinsicSensitivity "-2600" directive in their UCM config. I'm not sure if there is a way to apply a hidden 20db gain with ALSA so the volume controls will work properly. Docs: https://chromium.googlesource.com/chromiumos/third_party/adhd/+/refs/heads/main/docs/ucm.md#audio-nodes-cras

Answer 43 · 2024-10-06T20:19:15.000Z

@vulpes2 - first a big thank you for all your effort and double so for bringing all that to mainline of the corresponding projects which i would say is absolutely amazing ... regarding the mic gain boost, did you see my note in the readme of kukui to maybe use "pactl set-source-volume 1 400%" - 400% (i think that was the limit, but not completely sure anymore) would at least be 12db, still not 20db - maybe the more and more upcoming pipewire offers more options for such a fixed gain within the audio chain ... the target for the next round of images would be debian trixie where we should maybe try to switch to pipewire for audio if easily possible and if it would help for such things ...

Answer 44 · 2024-10-06T22:57:16.000Z

I did see the notes about the 400% volume with pulseaudio, I'm hoping there's a way to "hide" that 20db gain somewhere, so the end user still gets a "normal" 0-100% volume control that actually works as intended. I skimmed through the existing upstream UCM configs and they all use hardware gain controls, which is not available on this particular audio setup. PipeWire doesn't have the ability to apply audio gain transparently either.