Backlight class isn't present

[Scampada]

Oh, yes. I tried graphics-$(uname -r) and after it loaded my display went black and I had to do REISUB.
It wasn't pitch black as if the display went off, it was only black colored screen.

I tried Ctrl+Alt+Fn, tried Ctrl+arrows, tried Ctrl+Alt+Backspace, nothing worked. I dunno why this happened.

[Scampada]

Wow!

Look, I reloaded graphics extension once more, and what have I found? When it is loaded, my display goes totally black for a sec (as if it has been changing its video mode), then it lights up again but only to show black colored screen. But - the brightness buttons are working then! If I use 'em my black screen goes dim or bright.

So, I have now backlight support but for no purpose...

[gerald_clark]

Did you load the graphics extension before starting X?
Loading graphics extensions after starting X will cause display problems.

[Scampada]

I loaded graphics*.tcz before everything. I boot into CLI (as it is my main environment) and load graphics right after booting.

[Scampada]

Ir appears that after going black the system isn't stuck or something, it's working propely except of showing no picture.
I typed 'exitcheck.sh' command in black screen and my laptop turned off.

[gerald_clark]

Try adding nomodeset boot option.

[Scampada]

1. Added nomodeset. Booted the system and loaded graphics*. Display was working properly then but no effect gained. Brightness buttons was not working and the backlight dir was still empty.

2. Added graphics* contents right into core.gz, copying it over. After rebooting lsmod showed that some new modules are loaded, agpgart, intel_gpa, intel_gtt and something else, but brightness buttons didn't work and backlight dir was empty.

3. So it has effect ONLY if a) the core.gz doesn't include graphics* modules b) nomodeset option is not set c) user loads graphics* after booting normally and gets black screen... with brightness controls working.

I believe that if I type 'ls /sys/class/backlight > ~/test' when my display is black there will be all needed content present in the file, but~

[curaga]

Including modules in the initrd is no different to an extension, as long as they're properly integrated - depmod files updated.

I'm afraid you have a kernel bug in the i915 driver. Since other distros work, it's propably fixed in later kernels. Search for your model in the commit logs, etc.

[Scampada]

Including modules in the initrd is no different to an extension, as long as they're properly integrated - depmod files updated.

I know, but - there IS a difference though!
Well, never mind.

I'm afraid you have a kernel bug in the i915 driver. Since other distros work, it's propably fixed in later kernels. Search for your model in the commit logs, etc.

That is, I have to find and build a newer kernel, right?

[curaga]

Yes, but first find where it was fixed, rather than blindly try many versions. You might even find a simple patch to apply to our version.

[Scampada]

Linux kernel doesn't identify itself as Linux to the BIOS when the BIOS queries for the OS identification using the _OSI method. The intent and reasoning behind this decision to not identify itself as Linux is to eliminate the proliferation of Linux special handling cases in vendor platform BIOS code. Vendor special handling code could result in Linux kernel bugs and performance problems, especially when Linux can handle a feature better in the kernel and when the BIOS overrides it with a suboptimal implementation of its own. Essentially, vendor code specific to an OS introduces a tie between the OS and the platform based on assumptions that might be incorrect and/or no longer valid as OS features keep on evolving. Eliminating such special ties will lead to simpler maintenance model at both ends.

For more information on the _OSI strings Linux supports, please refer to the, struct acpi_interface_info acpi_default_supported_interfaces defined in drivers/acpi/acpica/utosi.c

With that background, now let's talk about why Linux cares about Windows 8 backlight control status. Windows 8 requires minimum backlight support level for platforms to run Windows 8, for example, at least 101 different brightness control levels. In Linux 3.7, the Linux kernel started returning true in response to BIOS _OSI query for Windows 8 to make BIOS enable enhanced Windows 8 required backlight features on the platform. The good thing is now the platform has enhanced backlight feature. However, this resulted in the issues related to lack of backlight support in drivers and broken platform backlight implementation to surface causing the backlight support in the Linux kernel unstable.

Linux is pretending to be Windows to cheat a little ahahahhaaha
Wait. Can I somehow set in boot options that, for example OSI=I am not Windows? Might it be the thing? I do not need enhanced backlight, just normal.
Or is it a permanent problem. And the only option is to update.

Yes, about updating: won't an incremental kernel patch broke some Tiny Core special tuning in the kernel source?

[Rich]

Hi Scampada
You might want to check out the  acpi_backlight=  and  acpi_osi=  boot codes.

[Scampada]

Hi Scampada
You might want to check out the  acpi_backlight=  and  acpi_osi=  boot codes.

Good daytime,
Yeah. acpi_backlight=vendor \ acpi_backlight=legacy \ acpi_osi=Linux
I have tried them already. Them didn't work, unfortunately.

[Scampada]

Is it true that I can take absolutely any one kernel version, apply the TC config file to it then build and get a proper TC system?

Or are there some TC-specific tunes that aren't stored in config and must be applied to the kernel source itself?

Just want to be sure. I can certainly take a TC kernel and apply a patch, but I would wish to know more. Before doing anything...

[Scampada]

Or are there some TC-specific tunes that aren't stored in config and must be applied to the kernel source itself?

I meant patches