Closed psstoyanov closed 3 months ago
I've not had reports of any GLK devices having issues with brightness control. your best bet for assistance is probably the chrultrabook Discord linux channel. They can help verify the correct backlight control type is being used
So far no movement in the Discord channel.
The values are indeed changing in /sys/class/backlight/intel_backlight/brightness
as expected but nothing observable on the unit.
I'm tempted to check with Tiny11 to verify if its Linux only or not.
31.0.101.2111
- interestingly night light works but no display brightness adjustment on this unit. Or at least whatever is being adjusted doesn't reflect on the backlight itself.Under Windows, does the backlight adjustment slider exist and not work, or not exist at all
It exists but doesn't work.
I didn't bother to check why the keyboard brightness buttons, touchpad and audio don't work. To adjust the brightness I've went through Settings -> Display
that most likely means the backlight control type for the display is incorrect in the VBT in the firmware. Does your device have an OLED panel ?
No - it's not OLED. It should be some LCD panel but I'm not sure of the model number or if the wacom stylus support introduces some variations on this 11" model.
hw-probe lists it as:
I have't used that software before so I can't be sure of its accuracy
boot linux with the following kernel param added: drm.debug=0xe
then get me the output of sudo dmesg | grep drm
so I can see what's going on with the backlight detection/control
Applied drm.debug=0xe
to /etc/default/grub
:
Result from dmesg | grep drm
:
Where are these firmware blobs fetched from?
@psstoyanov fetched from? They are built by me, and stored in the blobs repo as per the path
@psstoyanov fetched from? They are built by me, and stored in the blobs repo as per the path
Oh, nice! 👍 I thought for a second they had to be taken from some chromium repository or the like (being 3rd party and all)
no, they don't exist in any repo. Google builds them on the fly and includes them in the FW_MAIN_A/B regions. I build from the same branch but latest version and with a few tweaks
Interesting, ectool
throws invalid command:
$ sudo ./ectool backlight 0
EC result 1 (INVALID_COMMAND)
that's what I'd expect for a device without a keyboard backlight. The EC has nothing to do with the screen backlight.
This is confusing. Why is there LCD reference in the command? :confused: https://chromium.googlesource.com/chromiumos/platform/ec/+/master/util/ectool.c#74
maybe some ARM-based devices use the EC for backlight control? Intel/AMD ones do not
Alright some further progress. After I haven't used the device for.... nearly a year. What I find interesting is that the digitizer also gave the ghost rendering the touch functionality unusable. The Wacom stylus is still functional.
As a reminder, the original issue highlighted that I couldn't control the brightness of the LCD apart from completely shutting it down.
I've returned the device to stock firmware with the stock image (which should override with default HWID) and the backlight adjustment doesn't work there as well. My initial feeling was something about the HWID interfering with the correct hardware behavior.
Moving back and forth (as the tool can't override the original firmware while the system is using CrOS) - the original firmware is now back on the device.
Results of using the original firmware with correct HWID:
Looks like something gave the ghost. What exactly I'm not sure of. After some additional observation of the hardware, I can see "bubbles" forming in the lower part of the display (right where the data/ backlight connection of the LCD is behind the lid).
I suspect the relative who owned the device, induced water damage that slowly crept it's way through the unit (not sure if this was even registered or "worth remembering" as it was at least partially functional or functioning properly for some time).
I will send the device somewhere for further investigation or order a new display assembly.
In conclusion, using the custom firmware acts exactly as expected and none of the problems with this particular BOBBA360 have any connection to the scripts and the custom firmware.
@MrChromebox thank you for the support and for the incredible tool you've created! Once this little bobba360 is mended, you can be sure I will use the tool again 💯
Hi, I've installed the custom UEFI firmware on BOBBA360 device CP311-2HN with Fedora 38. I used EndevourOS img for secondary check.
Everything seems to work supririsngly well for daily operations with the exception of the brightness changes not being applied. It appears as if the values are changing but there is no observable difference on the unit's dispay. The same behaviour was observed on Gnome with Fedora 38 and XFCE with EndevourOS.
Has someone else observed similar behaviour?