Thanks. I'll study the DSDT a bit more to see if I can identify anything
else worth trying. There _must_ be some way to get everything working
after S3 like it was before ...
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you
Yes, after resume the screen brightness can only be changed by writing
to intel_backlight/brightness, not by writing to the respective
brightness file of either of the two other interfaces.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
And I assume that writing to the acpi_video0 and toshiba brightness
files still has no effect on the screen brightness with the kernel from
comment #37?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/93
Thanks! I'm afraid, with this patched kernel there isn't any noticeable
difference against the standard precise one. After suspend and resume
the acpi_video0 and toshiba interface still respect writing to each
other's brightness file, respectively, whereas
intel_backlight/actual_brightness still ex
jowi: I've got one more thing I'd like for you to test, if possible.
It's a bit of a guess based off of an observation, but I'd like to know
if it makes a difference.
Please remove toshiba-acpi-dkms and install the kernel from the link
below. Then reboot and see if there's any change in the backli
Oh, and I forgot something that could be of interest: I had to insert a
short sleep after modifying the brightness files before reading the
value of intel_backlight/actual_brightness. It seemed to need a little
amount of time before it reached its new value.
--
You received this bug notification
And the output after resume.
** Attachment added: "brightness_test-after_resume.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/+attachment/2971344/+files/brightness_test-after_resume.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I couldn't manage to post three attachments in one comment. So here
comes the output before suspend.
** Attachment added: "brightness_test-before_suspend.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/+attachment/2971343/+files/brightness_test-before_suspend.log
--
You rece
I don't know whether it may be helpful or even makes things more
complicated, I had another look to the values of the brightness and
actual_brightness files of the acpi_video0, toshiba and intel_backlight
interfaces under /sys/class/backlight, and how they change when writing
to it. A little script
That's very puzzling. It's good that it works, but I don't understand
the difference in behavior.
I'll think about it a little more, but right now I can't think of
anything else to test that will make a practical difference. It seems
like there ought to be a better way to fix this after suspend, s
Thanks, great! The machine suspends and resumes without failure. And
after resume the display brightness can now be changed by writing to the
toshiba interface's brightness file. The brightness file of acpi_video0
still doesn't work after resume, what probably causes the Fn-F6/7 keys
to not work ei
jowi: I've got one more build I'd like you to try, if you don't mind.
This is a technique that some people have reported as working, writing 1
to HCI_BACKLIGHT right after setting the brightness level. It may well
lock up your machine like the other attempts, but I'd like to at least
try it before
To be exact, I tried to write 1 when the value was 0 and vice versa. In
both cases the machine locked up.
I already read a bit about the problem on the net, so I think I have a
basic idea of what you mean about the problem behind.
Albeit not satisfying, at least the intel_backlight interface work
So as I understand your comment the machine is locking up any time you
try to write 0 or 1 to hci_backlight. Is that correct? If so, this isn't
looking very promising.
Just fyi, the process of what happens when HCI_BACKLIGHT is written is
completely opaque to us. The actual operations are handled
I'm afraid it's not that easy. The machine locks up immediately when
writing to hci_backlight as with your first patched version from comment
#8 on soft suspend. Regardless of whether I try to write a value of 0
after boot or 1 after suspend and resume. Not a single line in the logs,
it looks like
Doh, silly logic error reading the value being written. That's why it's
helpful when you're able to test your code :)
Fixed, please try the package below. It's useful to know that the value
is reset to 0 after suspend, and it will be interesting to see whether
simply writing 1 gets both the acpi_v
Thanks again. The value of hci_backlight is 1 after a fresh boot and 0
after supend and resume. I can't change it by writing to the file. "echo
0 | sudo tee hci_backlight" yields "tee: hci_backlight: Invalid
argument". Same result with "echo 1 ...".
--
You received this bug notification because y
Okay, I changed the name to hci_backlight. Please try the build below.
http://people.canonical.com/~sforshee/lp935778/toshiba-acpi-
dkms_0.6~lp935778v201203282134_all.deb
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.la
Hrm, seems the name I picked was a bad choice since a directory gets
created with the same name. I'll have to generate a new package with a
different name, but I'm not at the machine right now that has the code.
I'll post something a little bit later.
** Changed in: linux (Ubuntu)
Status: I
I recreated the directory listing with LANG=C, because the content-type
setting "text/plain; charset=utf-8" doesn't seem to be respected with
firefox.
** Attachment added: "Directory listing of /sys/bus/acpi/devices/TOS6208:00"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/+attac
** Attachment removed: "Directory listing of /sys/bus/acpi/devices/TOS6208:00"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/935778/+attachment/2957122/+files/dirlisting_TOS6208%3A00.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
It's TOS6208:00. In there is no "backlight" file, but a "backlight"
directory. This contains nothing but the single subdirectory "toshiba",
which is the link target of /sys/class/backlight/toshiba. A directory
listing is attached.
I hope you understand that I don't want to play with those files wi
Both of the paths in comment #19 should have had :00 at the end. Sorry
again.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935778
Title:
Toshiba R840 - brightness controls work on first boot, but d
Sorry, I gave you the wrong path for your machine, but there _should_ be
a backlight file somewhere if you've got the toshiba_acpi module loaded
from the package I supplied. Try /sys/bus/acpi/devices/TOS6208, or if
that's not there /sys/bus/acpi/devices/TOS6200.
--
You received this bug notificat
I'm sorry, but the backlight file doesn't get created. There is no
/sys/bus/acpi/devices/TOS1900:00. To be on the safe side I searched the
whole /sys tree, but didn't find any "backlight" file.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Good. Now for the next test build. What I did this time was add a new
file:
/sys/bus/acpi/devices/TOS1900:00/backlight
which I will simply call "the backlight file." This file will let you
read and write values directly to the register that is supposed to fix
the backlight issues after suspend.
The Tecra R840 affected by bug #962142 has an ATI graphics card and uses
the proprietary fglrx module, whereas James', who opened this bug here,
and mine have Intel processor graphics, which might also make at least
partly the difference between suspend failure and success. Of course
that's just a
I've put up a new test build. I'm slowly reintroducing the backlight
changes. I expect this one to have no functional impact for you; it
should only affect models that can't change the backlight settings via
toshiba_acpi. Please test and see if you notice any regressions from the
last build. Thanks
Bug 962142 reports a suspend problem with the R840, so the changes
you're testing may also have nothing to do with the suspend problem, or
may only affect it indirectly (e.g. changes the timing of suspend to
make the problem more prevalent).
--
You received this bug notification because you are a
Thanks for the new build. With this version of the module my Tecra
suspends and resumes successfully again. Before suspend pressing Fn-F6/7
still changes the brightness in all 8 steps as implied by the toshiba
interface. Besides that, I didn't recognize any other obvious difference
against the unpa
Thanks for clarifying. I have a new package that strips out the
backlight changes but keeps in the others, so we can see what's causing
your suspend regression. Please let me know whether you still see the
suspend issues with this build. Thanks!
http://people.canonical.com/~sforshee/lp935778/toshi
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935778
Title:
Toshiba R840 - brightness controls work on first boot, but do nothi
@Seth: Sorry for not having been clear enough.
Without your patched driver:
Suspend and resume work out of the box when suspend is initiated via
panel menu entry and without closing the lid. When I suspend by closing
the lid I have to disable the "lock screen after screen turns off"
setting, othe
jowi: Thanks for providing your test results. Can you clarify what you
mean by, "freezes on suspend or the backlight stays off on resume"? Do
you mean that sometimes one happens, and sometimes the other, or that
you just can't tell which is happening. The driver has quite a few
changes besides just
My Tecra R840 shows the exact symptoms as described before. I'm on
precise with all current updates (Linux brahms 3.2.0-20-generic
#32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64 x86_64 x86_64
GNU/Linux).
With and without Seth' patched driver from #8 (Thanks, Seth, for your
fine work. I already
I've put together some changes to toshiba_acpi based on my best guess as
to what's needed to fix this problem. Please install the dkms package
linked to below, then run "sudo modprobe -r toshiba_acpi; sudo modprobe
toshiba_acpi" to reload the driver. Please let me know whether or not
/sys/class/bac
It would be useful to test each individual interface before and after
resume by writing directly to the brightness files in sysfs to see which
work and which don't at any point in time.
Based on the first time you pressed Fn+F6 it looks like acpi_video0 is
being used to adjust brightness, since it
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935778
Title:
Toshiba R840 - brightness controls work on
Seth Forshee writes:
> It's hard to tell much from your ACPI tables, essentially they just seem
> to be handing everything off to the embedded controller. We'll have to
> experiment a little.
[...]
On first boot.
| root@ornery:/sys/class/backlight# ls -l
| total 0
| lrwxrwxrwx 1 root root 0 Fe
It's hard to tell much from your ACPI tables, essentially they just seem
to be handing everything off to the embedded controller. We'll have to
experiment a little.
If you look in /sys/class/backlight you'll have a directory for each of
the backlight interfaces available on your system. You should
Still present:
Linux ornery 3.2.0-17-generic #26-Ubuntu SMP Fri Feb 17 21:35:49 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
FWIW, Seth mentioned this patch when I talked to him on IRC about this bug,
but he says it would need work.
http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/2616
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Thank you for taking the time to file a bug report on this issue.
However, given the number of bugs that the Kernel Team receives during
any development cycle it is impossible for us to review them all.
Therefore, we occasionally resort to using automated bots to request
further testing. This is s
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935778
Title:
Toshiba R840 - brightness controls work on first boot, but do nothing
afte
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/935778
Title:
Toshiba R840 - brightness controls work on first boot, but do nothing
after suspend/resume
To manage notifications about this bug go to:
45 matches
Mail list logo
