Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: Scampada on July 31, 2015, 02:16:26 PM
-
Hi,
I was trying to find something in /sys/class/backlight to be able to change my screen brightness from CLI... But there is nothing. I put a boot laptop option, still no effect. Why? Is it something I have to tune inside my TC?
-
Output from modprobe -l | grep backlight shows:
kernel/drivers/video/backlight/generic_bl.ko.gz
kernel/drivers/video/backlight/lcd.ko.gz
kernel/drivers/video/backlight/bd6107.ko.gz
kernel/drivers/video/backlight/adp8860_bl.ko.gz
kernel/drivers/video/backlight/backlight.ko.gz
kernel/drivers/video/backlight/platform_lcd.ko.gz
kernel/drivers/video/backlight/adp8870_bl.ko.gz
kernel/drivers/video/backlight/kb3886_bl.ko.gz
kernel/drivers/video/backlight/apple_bl.ko.gz
Looks like I have even unnecessary ones but there is only an empty /sys/class/backlight directory.
-
Are you sure your hardware can do that? Anything there on another distro?
-
Yeah, sure. It's all OK under openSUSE, even brightness buttons are working fine. I found that in openSUSE there are two or three more kernel modules in
/lib/modules/$(uname -r)/kernel/drivers/video/backlight - gpio_backlight & pwm.bl. But it's not able to just copy them to TC, though. A pity.
What can I do?
My board is a netbook of 'Packard Bell dot s' series
http://www.ferra.ru/images/265/265157.jpg (http://www.ferra.ru/images/265/265157.jpg)
-
I can upgrade and rebuild the kernel, but... but... ohshi~
Are there TC 3.17.* kernel sources available? Does it depend strictly whether it's a TC kernel source or not? Can I manually compose a new TC compatible kernel source and build it?
-
Btw. When I close the notebook its display goes pitch black. Does it mean it works with backlight somehow, then?
Also, if I do not touch it for some time, the display also goes black until key pressed. Does it mean the same?..
Well, how could it ever draw something on the screen if it didn't work with backlight hardware?
lsmod | grep light:
backlight 12288 2 acer_wmi,video
It is used by video module, how could it all work fine if it was not even recognized?
I had also found something about backlight in /sys/module, but I'm not sure what is it.
There is also a maybe relevant dmesg string available:
[Firmware bug]: ACPI: BIOS _OSI(Linux) query ignored
-
Extra modules on disk may not be relevant. Compare lsmod on both, backlight-related modules.
Screen blanking when lid closed is done by hw, the screen saver is unrelated, and without sw control the backlight defaults to BIOS settings.
-
Erm, well. I found differences between TC's lsmod output and that one of openSUSE.
TC lsmod has:
acer_wmi, video, backlight
openSUSE has:
acer_wmi, video, NO backlight and some more additional modules that I am not sure are relevant. e.g. i915, i2c* and something.
(And backlight sw is present.)
One more difference is that TC is using kernel version 3.16.6 and openSUSE has 3.16.6-2. archlinux that I also have in possession and where backlight sw is working, uses even more up-dated 3.18.*
Maybe it depends on kernel version?.. maybe 3.16.6 can't recognize my hw and 3.16.6-2 can?
-
Then it's likely your backlight is managed by the Intel graphics card. See if the /sys dir is populated when you load the graphics- extension (in CLI, not in X!). If so, you need to use Xorg or Xfbdev, Xvesa cannot be used with KMS.
-
Then it's likely your backlight is managed by the Intel graphics card. See if the /sys dir is populated when you load the graphics- extension (in CLI, not in X!). If so, you need to use Xorg or Xfbdev, Xvesa cannot be used with KMS.
Usually, I have no X loaded (except when I'm running angband or dosbox).
Is it right that to use my backlight software properly I have to run Xorg?..
What should I do - when I load the graphics, wait, do I load it?.. Hmm. I shall check and see
-
Don't your keyboard function keys work to change the brightness?
If not try loading and starting acpid.
-
Don't your keyboard function keys work to change the brightness?
If not try loading and starting acpid.
For now, definitely not. Under openSUSE they do, in TC don't.
(But how would they if there weren't bl class?)
I will, thank you.
-
The problem isn't that i can't change backlight brightness with Fn keys, the problem is my system believes that I have no backlight at all.
I thought of, maybe openSUSE rewrites BIOS defaults, because after I start openSUSE and lower my brightness and then restart, the screen is dim in GRUB and in TC. And if I start openSUSE and set brightness higher the screen would be brighter under TC after reboot (and even after shutdown!).
So I thought, maybe, can I update those BIOS defaults from TC without configuring the backlight interface itself?.. That would be quite nice then, if these settings would store themselves permanently between sessions.
-
Funny that I can not remove the backlight module because it's "IN USE" or something, and still it doesn't create any content in /sys/class/backlight. Sure it's in use because my display is working... But it's used some wrong way.
-
Did you try graphics-? Xorg is not required, just mentioned that Xvesa is not compatible.
-
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.
-
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...
-
Did you load the graphics extension before starting X?
Loading graphics extensions after starting X will cause display problems.
-
I loaded graphics*.tcz before everything. I boot into CLI (as it is my main environment) and load graphics right after booting.
-
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.
-
Try adding nomodeset boot option.
-
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~
-
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.
-
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?
-
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.
-
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?
-
Hi Scampada
You might want to check out the acpi_backlight= and acpi_osi= boot codes.
-
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.
-
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...
-
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
-
If you compile a new kernel, you need to compile all the modules you need.
Some packages depend on extensions that are named after the kernel version.
You will need to create all these packages too.
-
And if I patch a TC kernel with an incremental patch, e.g. 3.16.6-7 then all those modules won't work too?..
-
Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.
-
Strange... I'm trying to rebuild a patched kernel. And something's wrong...
I have linux-3.16.6-patched.txz, fbcondecor-3.16.patch (and a linux-3.16.6-7.patch).
I extract kernel source then do patch -p1 < ../fbcondecor-3.16.patch then make.
All these files I also have used last time I had been rebuilding the core. A few months ago. They mustn't have changed. Last time I'd patched and typed make and there was no errors. Today I see "HUNK FAILED" and after trying 'make' it wastes my time for about half of a hour building and gets stuck with "recipe failed", obviously because of failed patch.
Strange... what could've happened
-
Hi Scampada
Today I see "HUNK FAILED" ...
This gives a couple of possibilities for the cause of that type of error:
http://stackoverflow.com/questions/14282617/hunk-1-failed-at-1-whats-that-mean
-
I have seen that Q&A article, thanks. 8) But this doesn't still make obvious why that would happen. The files I used were not being changed from last time I built the core...
PS Yeah. That what could have changed... is subdirectory level.
Then: patch -p1 < ../fbcondecor-3.16.patch
Now: patch -p1 < ../../fbcondecor-3.16.patch
I mean... Don't I need to set -p2 instead of -p1 in the last case?..
-
I mean... Don't I need to set -p2 instead of -p1 in the last case?..
I wasn't sure about this. -p2 option didn't work, so I just copied patches from ../../ to ../ and all is going well now.
Yet another gap in my experience. Or, maybe, yet another experience in my gap.
-
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.
You were right about a bug; I have rebuilt the core with a 3.16.7 patch and now backlight is working fine. There is small problems though, but they are not critical. The first is, new 3.16.7 modules folder for some reason weighs about 60 Mbs, while old 3.16.6 modules folder weighs about 7 Mbs. This ends up in very heavy core.gz, its weight is about 50 Mbs.
The second is, I don't even want to mention this, my fbcondecor splash vanishes when backlight module is loaded during boot... I will resolve this myself. Btw is there some early-stage splash for Tiny Core? Newer than fbcondecor which is a bit outdated.
-
The old modules folder only contains modules needed to boot and install on most systems.
The rest of the modules are in the various packages loaded by extensions that depend on them or by users that know they need them
for their hardware.
-
All right. So I could just compare both folders file list and drop all files from the new folder that aren't present in the previous?
-
Well, you also want the graphics and backlight modules, and maybe some others, so keeping the same set wouldn't be enough.
-
Sure, but default set contains backlight module.
Look, I have now 3.16.7 kernel and those extensions that have $(uname -r) in their names do not load at boot. The kernel looks for module-3.16.7.tcz and even when I try to load them manually they decline to load their dependencies for the same reason.
Is it correct if I just rename all extensions from e.g. alsa-modules-3.16.6-tinycore.tcz to alsa-modules-3.16.7-tinycore.tcz?Maybe it's a crude way.
I've tried to build the kernel with a bogus version string. There was said that version string is set inside of top level Makefile. There was base version=3, subversion=16 and something_else=7. I've changed 7 to 6 and started building. Nevertheless, modules were compiled as 3.16.7 and after I havebooted into new kernel uname-r showed out that I'm after all in 3.16.7.
So, what is the most accurate and elegant way to break make the system load all these modules that contain uname output in their names? Without a new rebuilding, please...
For now, I did something like this...
ln -s /etc/sysconfig/tcedir/optional/*3.16.6* /etc/sysconfig/tcedir/optional/*3.16.7*
and just in case
sudo ln -s /lib/modules/3.16.6-tinycore /lib/modules/3.16.7-tinycore
It seems for me that extensions' loading takes quite longer than before... it THINKS when loading
Hm... what if I do
alias uname -r='echo 3.16.6' ? ;D
well... kinda joke
-
As gerald_clark said
Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.
I'd say "the most accurate and elegant way" would be to create extensions using correct directory structure, containing the modules that were built when you compiled the kernel.
Alternatively, you could add modules to your initrd. This would use more RAM, though, depending on how much you'd add.
-
As gerald_clark said
Each kernel version has its own modules directory.
You can compile additional modules for an existing kernel, but when you compile a kernel with a different name, you also need all new modules.
I'd say "the most accurate and elegant way" would be to create extensions using correct directory structure, containing the modules that were built when you compiled the kernel.
Alternatively, you could add modules to your initrd. This would use more RAM, though, depending on how much you'd add.
1. Well,,, the most accurate way to do this quick.
But if I have to... I will. I would. I have to look how to unpack them first, then change their contents, then pack again, for I need not recompile them all I guess. Tcz-tools provides a packaging script, but tcz unpacking is too obvious to have an entire script for it, I believe. It's just a squashfs image, so... *mumbles*
2. I can. But I also will have to edit all tcz.dep's to remove module packages. Otherwise extensions will check for dependencies, right? And won't find them.
-
wget 'http://git.tinycorelinux.net/index.cgi?url=sorter/plain/sorter.sh'
That is the script we use to create the module extensions.
-
Remastered init and loadable modules with the given script. Now testing.
There was said that Xvesa does not support KMS. I do not know exactly what is KMS (just roughly) but when I started Xvesa habitually, and then tried to switch to console there was a black screen. So, I must abandon Xvesa... pity... It's a good little server. Definitely Xorg isn't an option. So only Xfbdev remains in the list, but doesn't it work slower than Xvesa because of substituting the X, not being it?
Links browser works slow when in framebuffer and quick when in Xvesa.
-
Xfbdev is slightly slower than Xvesa, but you can tune it with some options (see kernel vesafb docs). Should be faster than links in a framebuffer due to being X - the drawing routines are more optimized.
-
This makes little sense for me, but I occasionally started Xvesa with Xfbdev running and it looked like Xvesa started right INSIDE the Xfbdev session or something. Due to that I was able to switch to console from Xvesa session without getting blackscreen. When I terminated Xvesa with Ctrl-Alt-Backspace from inside of that it appeared that Xfbdevsession was terminated too.
Timeline:
1. Loaded Xfbdev and Xvesa extensions.
2. Started Xfbdev. There was a gray patterned screen.
3. Switched to console and started the script which purpose is to start Xvesa and then to start dosbox in it (my goal was to start dosbox but I got confused with commands).
4. Suddenly found myself in a Xvesa session having background picture and a dosbox window region.
5. Tried to switch to console and succeeded. Switched back to Xvesa.
6. Tried to switch to Xfbdev session with Alt-arrows and Fn's. It looked like there is no Xfbdev session just Xvesa one, so I came to decision that Xvesa is running right inside the Xfbdev.
7. Pressed Ctrl-Alt-Backspace and found myself in that very tty where the Xfbdev was initiated to start (not in that where I started the Xvesa-dosbox script).
It's up to me to explore how many memory is taken when both Xfbdev and Xvesa are running and how does it affect performance. If those values are low, this would be a very good strategy for me.
-
My TC after boot: ~32 Mb RAM used.
With Xvesa running without Xfbdev (default): 83.
With Xfbdev and Xvesa running altogether: ~85.
Looks nice. I take it. :)
Haven't seen yet if the speed is slower than usual, but I doubt it. At least this doesn't seem to be remarkable.
-
Hm,I'm not sure. Maybe I was confused with Xfbdev and no Xvesa is running, when its script is initiated. But all its configs are taken.