Suggestion: brunch-setup issue with kernel 6.12 (missing options like touchscreen )

[hiwuhgds-pixel]

Hello,

I've been using Brunch and noticed something with the brunch-setup script that I wanted to share, along with a temporary workaround that worked for me. I hope this feedback might be useful.

Observation

When I run the brunch-setup script and select kernel 6.12, it seems to only display one page of framework options. My understanding from looking at the script is that it should show two pages of options, similar to how it works for kernel 6.6.

I noticed this behavior across several different versions of Brunch (r134, r137, r139, r140). I also checked the script itself and could see that options_page2 is indeed defined for kernel 6.12, so the options should be available.

A Possible Theory

I'm not an expert, but my guess is that this might be related to how the shell environment handles variables.

I suspect that the options_page2 variable might already exist as an empty string in the shell environment before the case statement is executed. If that's true, the condition if [ ! -z "$options_page2" ], which checks if the second page of options should be displayed, might not work as expected.

A Temporary Workaround I Found

Based on this idea, I tried making a small change to the script by adding unset options_page2 right before the case statement.

My change (around line 190 of brunch-setup):

reset
unset options_page2
case "$selected_kernel" in
  6.12)
    #...

Result on My Machine

After adding that single line, the script started working as I had hoped. When I chose kernel 6.12, it correctly showed "PAGE 1/2" and then "PAGE 2/2". My device was then able to load the modules from the second page of options and has been working normally since.

I'm not sure if this affects other users or if it's just something specific to my setup, but I wanted to share my experience in case it helps.

Thank you for all your hard work on this project!

---

Edit:

I think the issue is more complicated than I initially thought. The solution above was just an experiment that luckily managed to solve the problem. The unset command seems to act merely as a "stabilizer" that resets the state.

The root cause is likely that the shell interpreter isn't behaving as expected (in fact, I've seen others in this issue report the same problem with kernel 6.6, not just 6.12 as in my case). Perhaps we'll just have to wait for a proper fix from the developer. xD

[olekor]

I apologize if this is a silly question; I'm not very experienced with this. I recently installed Chrome OS on my Surface Pro 8, and I need to enable the touchscreen functionality. Please tell me where the brunch-setup script is located. Also, can I edit it using Notepad? Thank you!

[hiwuhgds-pixel]

I apologize if this is a silly question; I'm not very experienced with this. I recently installed Chrome OS on my Surface Pro 8, and I need to enable the touchscreen functionality. Please tell me where the brunch-setup script is located. Also, can I edit it using Notepad? Thank you!

Hi @olekor,
I see you're looking to enable the touchscreen on your Surface Pro 8.
If your main goal is just to get the touchscreen working, there is a much simpler solution than editing the script:

1. Reboot your device.
2. When you see the GRUB menu, choose "Brunch settings".
3. Instead of selecting kernel 6.12, please choose kernel 6.6.
4. The setup process for kernel 6.6 correctly displays both pages of options (including PAGE 2/2), which will allow you to find and enable the touchscreen modules there.
   To answer your direct questions, finding and editing the brunch-setup script is a very technical process and requires significant effort. I would only recommend attempting this if you have a good technical background.
   • You cannot edit it using Notepad, as the file is located inside Linux image files.
   • You would need to use a Linux environment (like WSL on Windows or a live Linux USB) to mount the rootc.img file.
   • Inside rootc.img, you would then find another file named initramfs.img.
   • You would have to unpack or mount that initramfs.img file as well, and inside it, you would find the script located at /sbin/brunch-setup.
   Given this complexity, I highly recommend you try the first method (switching to kernel 6.6).
   Hope this helps!

[olekor]

Thank you for your detailed response. I'm a bit skeptical about the kernel selection because I’ve already attempted that before, but the settings were lost, and I had to reinstall Chrome OS. I will try it again to see if it works this time.

[olekor]

Unfortunately, switching to kernel 6.6 didn't work. First, "Brunch settings" didn't open from the GRUB menu. Then, I tried "Open a TTY with Ctrl + Alt + F2 and login as chronos." As expected, when I selected kernel 6.6, I didn't see PAGE 2/2; I only saw one page. After rebooting, I was unable to access the Surface keyboard to log in. I logged in as a guest, but using the on-screen keyboard to open a TTY with Ctrl + Alt + F2 also didn't work. So, need to reinstall Chrome OS, but without a working touchscreen, this option is unacceptable for my purposes, as a portable device.
From my previous experience using FydeOS/BlissOS/hackintosh on Surface Pro 4,5,6,7,8, I assumed ChromeOS would be less problematic, but it's the same dance with tamburine, so I'll have to stick with Windows, which is more familiar and understandable to my mind, although it's not very convenient and more power-hungry to use as portable.

[hiwuhgds-pixel]

Unfortunately, switching to kernel 6.6 didn't work. First, "Brunch settings" didn't open from the GRUB menu. Then, I tried "Open a TTY with Ctrl + Alt + F2 and login as chronos." As expected, when I selected kernel 6.6, I didn't see PAGE 2/2; I only saw one page. After rebooting, I was unable to access the Surface keyboard to log in. I logged in as a guest, but using the on-screen keyboard to open a TTY with Ctrl + Alt + F2 also didn't work. So, need to reinstall Chrome OS, but without a working touchscreen, this option is unacceptable for my purposes, as a portable device.
From my previous experience using FydeOS/BlissOS/hackintosh on Surface Pro 4,5,6,7,8, I assumed ChromeOS would be less problematic, but it's the same dance with tamburine, so I'll have to stick with Windows, which is more familiar and understandable to my mind, although it's not very convenient and more power-hungry to use as portable.

First of all, are you using ChromeOS to dual-boot or as a standalone installation?
The problem likely occurred because the interpreter (bash busybox) is not working as expected.
In my experience, once this happens, any attempt to fix it through the Brunch settings or by entering the rootshell (Ctrl + Alt + F2) is useless XD.
The best way is to do a complete reinstallation from scratch (if you feel that creating the chromeos.img is taking too long, there is actually a way to make this process much faster).
I have an idea for an easier temporary fix; I'll probably send the guide in a bit. You can try it.

[olekor]

I have an idea for an easier temporary fix; I'll probably send the guide in a bit. You can try it.
Thank you for your prompt response. I would greatly appreciate it if you could provide your variant recovery option

[hiwuhgds-pixel]

I have an idea for an easier temporary fix; I'll probably send the guide in a bit. You can try it. Thank you for your prompt response. I would greatly appreciate it if you could provide your variant recovery option

Normally, any options you select in the "Brunch settings" menu (during boot) are saved to the settings.cfg file. Therefore, if you are encountering the issue where Page 2 options (especially for "touchscreen") are not appearing, the temporary fix is to edit the settings.cfg file directly, as shown in the video.

The video demonstrates this process at the stage after you have downloaded both the Brunch and ChromeOS recovery files. Instead of just extracting the Brunch archive and then proceeding, you should extract the Brunch archive, edit the settings.cfg file at this moment (as shown), and then continue with the rest of the installation process as usual.

Please note: The video only demonstrates adding the ithc option and changing the kernel version. If you need to add other options, parameters, etc., you should proactively add them all directly to the file during this step. It is not recommended to try and add them later via the "Brunch setting" menu.
Oh, and the part about saving and exiting the settings.cfg file might be a bit confusing.

You need to press Ctrl+X, then type Y to confirm saving, and finally press Enter.

It is recommended to run the sudo nano settings.cfg command again to re-enter the file and double-check that all your information was saved correctly.
https://youtu.be/NpVOrg80vBw?si=xMgn9WShYWlPRppC

[olekor]

Thank you again. I'll give that a try to see if it works. Regarding the kernel version number, in the "Build Brunch against ChromeOS r139," the default is 6.12, correct? I'm currently using the recovery image: chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin.

Could you clarify how the other kernel versions listed in the "Brunch settings" apply when using a different recovery image? I attempted to find out which kernel version I had before the crash, but I wasn't able to do so using the -r command in the Linux terminal after I set up the developer environment before the ChromeOS crash

[olekor]

@hiwuhgds-pixel

I followed the video tutorial and made the necessary edits, but when I started installing Brunch/ChromeOS, I encountered a problem. Despite several attempts to resolve this issue, I was unable to find a solution
root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# mkdir /mnt/c/brunch/chromeos
root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# sudo bash chromeos-install.sh -src chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin -dst mnt/c/brunch/chromeos/chromeos.img -s 40
Desination path does not exist, please provide an existing path.
root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads#

[hiwuhgds-pixel]

@hiwuhgds-pixel

I followed the video tutorial and made the necessary edits, but when I started installing Brunch/ChromeOS, I encountered a problem. Despite several attempts to resolve this issue, I was unable to find a solution root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# mkdir /mnt/c/brunch/chromeos root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# sudo bash chromeos-install.sh -src chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin -dst mnt/c/brunch/chromeos/chromeos.img -s 40 Desination path does not exist, please provide an existing path. root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads#

All recent versions support two kernel versions, 6.6 and 6.12. You can use either one.
Your error is because the destination path is missing a /. The correct command should be:

sudo bash chromeos-install.sh -src chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin -dst /mnt/c/brunch/chromeos/chromeos.img -s 40

[olekor]

@hiwuhgds-pixel
I followed the video tutorial and made the necessary edits, but when I started installing Brunch/ChromeOS, I encountered a problem. Despite several attempts to resolve this issue, I was unable to find a solution root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# mkdir /mnt/c/brunch/chromeos root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads# sudo bash chromeos-install.sh -src chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin -dst mnt/c/brunch/chromeos/chromeos.img -s 40 Desination path does not exist, please provide an existing path. root@SurfacePro8:/mnt/c/Users/Surface Pro 8/Downloads#

All recent versions support two kernel versions, 6.6 and 6.12. You can use either one. Your error is because the destination path is missing a /. The correct command should be:

sudo bash chromeos-install.sh -src chromeos_16371.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin -dst /mnt/c/brunch/chromeos/chromeos.img -s 40

Thank you very much for your support. I installed the system, but the touchscreen still isn't working. I have doubts about whether I should attempt to set up the Brunch Configuration, although I doubt it will fix the issue. This issue may be specific to the Surface. Based on my previous experience with Linux and Hackintosh installations, I used workarounds to get the touchscreen and Wi-Fi functioning on Surfaces 4, 5, 6, and 7. However, Surface 8 likely has different issues, and I haven't found any real-world examples of it working with Chrome OS. For now, I'll use it as is and see how it goes. Time will tell if this was worth it.
Thank you again for your support. Good luck with everything!

[olekor]

After updating Brunch, I tested the touchscreen by installing BRUNCH/ChromeOS on a flash drive. Two pages show available touchscreen options. But using a touchscreen is quite frustrating. Navigating pop-up menus, especially along the screen edges and in the lower right corner where the power, Wi-Fi, and other control buttons are located, is particularly difficult. Here, the touchscreen does not respond at all, regardless of whether I use my fingers or a stylus. I'm curious if there is a calibration utility available, similar to what you find in Windows. I came across a mention of Desk Sync, which is intended for users with external touch displays in ChromeOS 139, but it is supposedly for the original Chromebooks.

[hiwuhgds-pixel]

Regarding your question:

I'm curious if there is a calibration utility available, similar to what you find in Windows.

Unfortunately, the answer is no. ChromeOS doesn't have a graphical calibration utility for end-users like in Windows. Calibration is handled automatically at the driver level (the ithc module in this case).

I don't have enough data to be certain of the cause, but I have two theories: it's either a driver mapping error (it's reporting the wrong screen dimensions) or the system is missing the correct calibration data for your hardware.

There's also a high chance that loading the ithc module and driver failed.

You can try to test this by pressing Ctrl + Alt + F2 to open a TTY (shell), logging in as chronos/root, and then running the command:

sudo evtest

It will display a list of input devices. Find the device named "Touchscreen," "ITHC," or "ELAN." Type the corresponding number for that device and press Enter.

Now, touch the "dead zones" on the screen (the bottom-right corner, the edges) with your finger or stylus.

Analysis of the results:

Scenario A: The terminal displays a stream of codes/numbers when you touch the dead zone.

Meaning: The driver is working! The kernel is receiving touch data from those areas.

Cause: This is a calibration problem. The ChromeOS GUI (Freon/Wayland) is misinterpreting this data, thinking those coordinates are off-screen, and ignoring them.

Scenario B: The terminal displays nothing when you touch the dead zone (but it works in the middle of the screen).

Meaning: This is a deep driver/firmware error. The ithc driver (or whatever driver is being used) is not fully compatible with the Surface Pro 8 hardware and is not receiving any signals from those areas.

Alternatively, you can try running this command in the same shell to see if any errors were reported during boot:

dmesg | grep -i -E "(touch|stylus|ithc|input|error|failed)"

There's one more possibility: the shell interpreter is acting up again. Even though the two pages of options have returned, it's possible that brunch.config isn't actually loading the extra modules (because the interpreter is processing the data incorrectly). I've experienced this myself, which is why I often recommend that creating a new image from scratch is the best fix.

And are you sure you aren't confusing ithc with ipts? They are different drivers.

To be honest, I'm a bit confused about your setup. I see you are using the chromeos_16371.65.0... image (which is r140), but the latest Brunch version released is r139. What did you mean when you said, "After updating Brunch"? Starting from version r140, did you update to r141 from within ChromeOS (like an OTA update)?

Even if a Brunch version (like r139) supports a newer ChromeOS image, it can still be buggy. My advice is to always use the recommended corresponding image for your Brunch release (e.g., Brunch r139 is built for ChromeOS r139) to have fewer problems.

[olekor]

@hiwuhgds-pixel

I selected the "ithc" parameter for the Surface 7+ and above. When I mentioned "After updating Branch," I was referring to the edits made in the "Brunch settings" from the video. I chose the chromeos_16371.65.0 image because it was recommended for 11th-gen Intel, assuming it would be appropriate.
So, if using "Brunch version r139," I should use the chromeos_16328.65.0_volteer_recovery_stable-channel_VolteerMPKeys-v13.bin. I will try it later, maybe it will be more stable.
Do you think there will be a new release of Brunch?
Many thanks for the advice!

[olekor]

I ran several test variants, as shown in the pictures.
Initially, I selected /dev/input/event19, labeled "Intel Touch Host Controller Touchscreen." Unfortunately, the touch functionality did not respond. After a reboot, I then selected /dev/input/event24, labeled "IPTS Touch," and the touchscreen worked across the entire screen. When I rebooted the system again, everything continued to function properly, and I was even able to enter my password at the login screen, which hadn't worked before.

To ensure it wasn't a fluke, I rebooted once more. The same issue persisted, so I chose "ipts_touchscreen" for experimental purposes, but the sensor did not respond. I reverted to "ithc_touchscreen" and tested /dev/input/event24 (IPTS Touch) again. Initially, it didn't work properly after the reboot, but after a while, everything functioned correctly.

One issue I encountered is that when I attempt to turn off the tablet using the touch button in the right corner, a white screen remains, and I have to press the tablet's power button to turn it off completely. This might be related to running Chrome OS from a flash drive. Additionally, during testing, the devices 26 (IPTS Touch) and 27 (IPTS Stylus) occasionally disappeared and reappeared after each reboot.

I plan to test this setup on a portable Chrome OS installation from a flash drive for a while, and if everything works smoothly, I will switch to the tablet's SSD.