Open hexdump0815 opened 2 years ago
alpenamilch
commented
1 year ago 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?
hexdump0815
commented
1 year ago yes - that should be the correct way
vulpes2
commented
8 months ago @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.
Will investigate in these when I have more time.
v4l2-request works at all on this platform.No valid DP mode provided.iio-sensor-proxy to be installed and running for them to work with GNOME.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. hexdump0815
commented
8 months ago @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: https://github.com/hexdump0815/linux-mainline-mediatek-mt81xx-kernel/commit/6a3ca0b79dc357fbad142596ba65c3edc2c530ed - i did not find solutions for them yet
vulpes2
commented
8 months ago 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 .
vulpes2
commented
8 months ago 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=falseThis 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:1000Tested 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>;
};
};
janamach
commented
8 months ago 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).
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.Do you think upgrading to kernel 6.5 or 6.6 would fix the screen rotation issue?
vulpes2
commented
8 months ago 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.
janamach
commented
8 months ago 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?
hexdump0815
commented
8 months ago 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.
vulpes2
commented
8 months ago @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
janamach
commented
8 months ago @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:
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.
vulpes2
commented
8 months ago 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.
janamach
commented
8 months ago 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?
hexdump0815
commented
8 months ago @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
tech-with-mo
commented
5 months ago 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.tabletand then runlibwacom-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=falseThis is the libinput quirks file that fixes the trackpad and pen digitizer pressure range, place at
/etc/libinput/local-overrides.quirksand 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!
cheungyau2022
commented
4 months ago 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!
vulpes2
commented
4 months ago 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.
osfanbuff63
commented
3 months ago 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 https://github.com/hexdump0815/imagebuilder/issues/53#issuecomment-1837137317)
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?
janamach
commented
3 months ago @osfanbuff63 are you looking for this or something else?
https://github.com/hexdump0815/imagebuilder/blob/main/systems%2Fchromebook_kukui%2Freadme.md
osfanbuff63
commented
3 months ago Those still run on XFCE last time I tried, but I'll check it again to make sure
thenameisluk
commented
1 month ago 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
hexdump0815
commented
1 month ago @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) :)
thenameisluk
commented
1 month ago 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
hexdump0815
commented
1 month ago @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
thenameisluk
commented
1 month ago lack of compressing is least of my concerns since it doesn't boot also we should probably move this discussion to a separate issue
tech-with-mo
commented
1 month ago Hi, are we expected to get any new updates for the new Ubuntu releases (23, 24)?
thenameisluk
commented
1 month ago @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
hexdump0815
commented
1 month ago @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 https://github.com/hexdump0815/kernel-config-options/commit/592147c6c98944aed337af6003d79fc8e3f524c6 ) ... newer images will come, its just not clear yet when
thenameisluk
commented
1 month ago @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?
hexdump0815
commented
1 month ago @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
thenameisluk
commented
1 month ago @hexdump0815 i tested it it's bronke on trogdor
kukui
but works on corsola
would it be good idea to use the chromebook spin of kelner for kukui/trogdor?
hexdump0815
commented
1 month ago @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.
thenameisluk
commented
1 month ago @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
hexdump0815
commented
1 month ago @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)
thenameisluk
commented
2 weeks ago 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
thenameisluk
commented
2 weeks ago 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 Hubbut 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 directorylooks 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
Notes on krane running 5.18.1 - for updated information please have a look at this comment below: https://github.com/hexdump0815/imagebuilder/issues/53#issuecomment-1837137317:
Here is list of working and non working features on the lenovo chromebook duet 10.1 (krane).
Working
untested
broken
Installation
coming soon
PROBLEMS
none so far