Re: Questions on adding backlight support for the i915 driver
On 1/30/15 6:16 PM, Adrian Chadd wrote: Hi, Which chipset is it? Loading acpi_video causes a handful of interconnected pieces to shift (as IIRC at that point acpi_video also states that it wishes to take control of video setting, not just leave it all up to ACPI to drive itself.) There's a bunch of discussion / code churn in the linux dri2/i915 code (/past/ the point in 2012 that our code is currently synced to) about how to manage backlights. A lot of it seems due to ridiculously large variations in how backlights are actually managed. So, if we're going to do this, I think we should actually have a generic backlight thing that figures out if the right thing to do is talk to the underlying device/panel, rather than hang backlight controls off of each driver. It may not always be off of drm. :( There's also stuff surrounding locking and state changes, as well as restoring backlight values after a suspend/resume cycle. That kind of weird crap. I think we should get a few examples working so we have multiple things to generalize from. Also, so far the focus has only been on laptop LCDs. I've no idea if any external monitors support software backlight control. If they do, then that might put another wrinkle in, as what you really want is something like hw.backlight.monitor to hang control nodes off of (or you want to do it in userland). (Ideally we'd use the same labels for monitor that xrandr uses for outputs. I think the drm2 drivers are also using those labels for some controls now.) For now I would start with Elizabeth's current patch of exposing the raw i915 stuff via a sysctl. We can always remove this later if need be. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On Sat, Jan 31, 2015 at 10:21 PM, Alexandr Krivulya shur...@shurik.kiev.ua wrote: 31.01.2015 10:30, Miguel Clara пишет: On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers elizab...@interlinked.me wrote: On 01/31/15 02:15, Miguel Clara wrote: Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- If your keys work (as in, they do things in FreeBSD), does sysctl and the keys work together just fine with no weird effects? The only weird problem I could possibly think of that could come up is that the keys do a simple add/subtract to the PCM values, and so the brightness ends up wrong. See if that happens. Well, in the HP the keys don't do nothing it seems not even xev reports anything when I use them, but they could be wrongly mapped maybe... On the acer I do see keycodes from xev, but Im using lumina and If I try to map them to anything it doesn't work... I'll see what happens after reboot though. All works fine (sysctl and Fn-keys) on my Thinkpad E530 with IvyBridge! I my case it seems the issue wih the keys is that FreeBSD doesn't really know about them. In the Acer laptop, it compiled and installed fine, and after reboot the sysctl works awesome, but I add to map the keycodes in fluxbox: None 239:Exec intel_backlight decr None 123:Exec intel_backlight incr I use the intel_backlight program still cause its easier to send the decr and incr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On Sun, Feb 1, 2015 at 2:47 PM, Miguel Clara miguelmcl...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:21 PM, Alexandr Krivulya shur...@shurik.kiev.ua wrote: 31.01.2015 10:30, Miguel Clara пишет: On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers elizab...@interlinked.me wrote: On 01/31/15 02:15, Miguel Clara wrote: Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- If your keys work (as in, they do things in FreeBSD), does sysctl and the keys work together just fine with no weird effects? The only weird problem I could possibly think of that could come up is that the keys do a simple add/subtract to the PCM values, and so the brightness ends up wrong. See if that happens. Well, in the HP the keys don't do nothing it seems not even xev reports anything when I use them, but they could be wrongly mapped maybe... On the acer I do see keycodes from xev, but Im using lumina and If I try to map them to anything it doesn't work... I'll see what happens after reboot though. All works fine (sysctl and Fn-keys) on my Thinkpad E530 with IvyBridge! I my case it seems the issue wih the keys is that FreeBSD doesn't really know about them. In the Acer laptop, it compiled and installed fine, and after reboot the sysctl works awesome, but I add to map the keycodes in fluxbox: None 239:Exec intel_backlight decr None 123:Exec intel_backlight incr I use the intel_backlight program still cause its easier to send the decr and incr. Forgot to add The acer is running FreeBSD 10 (stable/10) so eventually this could be merged! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
I have a sort of rough draft of this. I've tested all the percentages (Ivy Bridge) and they do seem to correlate linearly (and to the intel_backlight userland program used by a lot of people). I haven't been able to test on any other hardware as I don't have it, and I don't know what chipsets require the value to be inverted, so I've not implemented that. If anyone else would like to help test, it'd be nice. Thank you Elizabeth for the patch. It works on my Samsung Ativ Book 2 with Ivy Bridge. I have modified the patch for 11-CURRENT and corrected these little bugs: 1) is possible to specify a percentage greater than 100% eg. with the command: ‘sysctl hw.dri.0.i915_backlight=111’ is possible to set the hardware register above the maximum allowed. 2) the percentage values are truncated instead of rounded: if I set 10% with the intel_backlight program is reported as 9% with the command ‘sysctl hw.dri.0.i915_backlight’: # intel_backlight 10 current backlight value: 20% (976/4882) set backlight to 10% (488/4882) # sysctl hw.dri.0.i915_backlight hw.dri.0.i915_backlight: 9 but 488/4882 is more near to 10% than 9% I have tested the patch with: # uname -a FreeBSD ativ 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r277961: Sat Jan 31 06:03:15 CET 2015 root@ativ:/usr/obj/usr/src/sys/GENERIC amd64 The patch is available at: http://pastebin.com/vKK7026H Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/31/15 02:15, Miguel Clara wrote: Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- If your keys work (as in, they do things in FreeBSD), does sysctl and the keys work together just fine with no weird effects? The only weird problem I could possibly think of that could come up is that the keys do a simple add/subtract to the PCM values, and so the brightness ends up wrong. See if that happens. -- Cheers, Elizabeth Myers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 17:16, Adrian Chadd wrote: Hi, Which chipset is it? Oh, I missed this, sorry. I have an Ivy Bridge chipset. Loading acpi_video causes a handful of interconnected pieces to shift (as IIRC at that point acpi_video also states that it wishes to take control of video setting, not just leave it all up to ACPI to drive itself.) My laptop doesn't have any ACPI calls for backlight stuff. Dell laptops seem to do it with SMI's. It's pretty lame (and exotic) stuff. There's a bunch of discussion / code churn in the linux dri2/i915 code (/past/ the point in 2012 that our code is currently synced to) about how to manage backlights. A lot of it seems due to ridiculously large variations in how backlights are actually managed. So, if we're going to do this, I think we should actually have a generic backlight thing that figures out if the right thing to do is talk to the underlying device/panel, rather than hang backlight controls off of each driver. It may not always be off of drm. :( There's also stuff surrounding locking and state changes, as well as restoring backlight values after a suspend/resume cycle. That kind of weird crap. A generic backlight module is probably ideal. Not everything uses ACPI to drive the backlight (my laptop doesn't). The way it could work is that drivers just provide the needed functions for changing the backlight and tell the driver hey here's my functions for backlight change and query. That way anything can take advantage of it, including acpi_video, providing a nice and unified interface. But I'd start with which chipset it is, which version of FreeBSD it is, and whether the ACPI stuff would work for you with a code update. But for a more general future thing, I'd rather we had a sysctl tree of actual display devices, each one mapping to the underlying thing it's controlling, so it's a generic API for both getting and setting values for the various displays that are hooked into things. A code update won't do any good due to aforementioned issues. If anyone else has a Dell laptop and would be interested in helping to test, I will try to write a driver for them. In the meantime, I think there should be some other discussion elsewhere or in another thread about a generic backlight framework. -- Cheers, Elizabeth ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- Melhores Cumprimentos // Best Regards --- *Miguel Clara* *IT - Sys Admin Developer* *E-mail:*miguelmcl...@gmail.com www.linkedin.com/in/miguelmclara/ On Sat, Jan 31, 2015 at 6:17 AM, Adrian Chadd adr...@freebsd.org wrote: On 30 January 2015 at 22:13, Elizabeth Myers elizab...@interlinked.me wrote: On 01/30/15 23:20, Adrian Chadd wrote: Do you have brightness buttons anywhere? What happens when you set it through this API and then you use the backlight buttons? I do, but FreeBSD doesn't have the needed WMI doodads to interact with this, nor do I have the needed Dell laptop doodads in the kernel to test otherwise. To get /those/ working will require something else entirely. I have been looking at the Linux drivers: https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-wmi.c https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-laptop.c I'll save those for another day though, this is a bit off-topic. If anyone else has laptop keys I'd like to see how they interact too. *nod* cool. I don't have any Dell hardware and I have no idea how any of that holds together. :( I'll wait and see what kib/jhb say and if there aren't any issues I'll commit your i915 debug patch. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers elizab...@interlinked.me wrote: On 01/31/15 02:15, Miguel Clara wrote: Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- If your keys work (as in, they do things in FreeBSD), does sysctl and the keys work together just fine with no weird effects? The only weird problem I could possibly think of that could come up is that the keys do a simple add/subtract to the PCM values, and so the brightness ends up wrong. See if that happens. Well, in the HP the keys don't do nothing it seems not even xev reports anything when I use them, but they could be wrongly mapped maybe... On the acer I do see keycodes from xev, but Im using lumina and If I try to map them to anything it doesn't work... I'll see what happens after reboot though. -- Cheers, Elizabeth Myers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
31.01.2015 10:30, Miguel Clara пишет: On Sat, Jan 31, 2015 at 8:19 AM, Elizabeth Myers elizab...@interlinked.me wrote: On 01/31/15 02:15, Miguel Clara wrote: Working fine on a HP running current as I've noted in the other thread as for the keys. This one (and most HP Pavillion models) use the Fn+F(2/3) but the keys, and my Acer (and I think not all are like this) use Fn+-/- If your keys work (as in, they do things in FreeBSD), does sysctl and the keys work together just fine with no weird effects? The only weird problem I could possibly think of that could come up is that the keys do a simple add/subtract to the PCM values, and so the brightness ends up wrong. See if that happens. Well, in the HP the keys don't do nothing it seems not even xev reports anything when I use them, but they could be wrongly mapped maybe... On the acer I do see keycodes from xev, but Im using lumina and If I try to map them to anything it doesn't work... I'll see what happens after reboot though. All works fine (sysctl and Fn-keys) on my Thinkpad E530 with IvyBridge! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 1/28/15 1:38 AM, Elizabeth Myers wrote: Hello, I want to add backlight support to the i915 driver in FreeBSD. It seems that two magic addresses are read and wrote from to change the backlight itself. It supports rather fine-level granularity all the way down to zero. Right now I use a hacked-up userland program that reads from/writes to these addresses, which is far from an ideal solution. I am interested in this because the acpi_video(4) driver does not support my backlight on my Dell Inspiron 15 3521 (not terribly suprising, on Linux I needed a special Dell-specific driver, and I'm not sure even that really used ACPI, I never really checked). My questions are really twofold: 1) How can this be exposed appropriately? I would prefer this be exposed generally so upower could grok it. As far as I can tell upower uses hw.acpi.video.lcd0 to control backlight. I am not sure that upower is doing the right thing here, though. 2) Where would the code go for this? The dri2 driver seems the most logical place, but maybe it belongs in X and exposed via a program? Or something else entirely that I'm not thinking of? I have experience developing PCI drivers and doing other PCI related doodads, and some kernel development experience, as well as general C experience, but I'm not by any means an expert on the matter. Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 09:17, John Baldwin wrote: Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) I'm wondering if that's the correct place for it to live. So far it's the only real place it *can* live that makes logical sense imho, unless anyone has better ideas. This is awesome. As for upower, it should probably be patched to know about other types of brightness sysctls if/when this is implemented. -- Cheers, Elizabeth ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
Hi, Which chipset is it? Loading acpi_video causes a handful of interconnected pieces to shift (as IIRC at that point acpi_video also states that it wishes to take control of video setting, not just leave it all up to ACPI to drive itself.) There's a bunch of discussion / code churn in the linux dri2/i915 code (/past/ the point in 2012 that our code is currently synced to) about how to manage backlights. A lot of it seems due to ridiculously large variations in how backlights are actually managed. So, if we're going to do this, I think we should actually have a generic backlight thing that figures out if the right thing to do is talk to the underlying device/panel, rather than hang backlight controls off of each driver. It may not always be off of drm. :( There's also stuff surrounding locking and state changes, as well as restoring backlight values after a suspend/resume cycle. That kind of weird crap. But I'd start with which chipset it is, which version of FreeBSD it is, and whether the ACPI stuff would work for you with a code update. But for a more general future thing, I'd rather we had a sysctl tree of actual display devices, each one mapping to the underlying thing it's controlling, so it's a generic API for both getting and setting values for the various displays that are hooked into things. -adrian On 27 January 2015 at 22:38, Elizabeth Myers elizab...@interlinked.me wrote: Hello, I want to add backlight support to the i915 driver in FreeBSD. It seems that two magic addresses are read and wrote from to change the backlight itself. It supports rather fine-level granularity all the way down to zero. Right now I use a hacked-up userland program that reads from/writes to these addresses, which is far from an ideal solution. I am interested in this because the acpi_video(4) driver does not support my backlight on my Dell Inspiron 15 3521 (not terribly suprising, on Linux I needed a special Dell-specific driver, and I'm not sure even that really used ACPI, I never really checked). My questions are really twofold: 1) How can this be exposed appropriately? I would prefer this be exposed generally so upower could grok it. As far as I can tell upower uses hw.acpi.video.lcd0 to control backlight. I am not sure that upower is doing the right thing here, though. 2) Where would the code go for this? The dri2 driver seems the most logical place, but maybe it belongs in X and exposed via a program? Or something else entirely that I'm not thinking of? I have experience developing PCI drivers and doing other PCI related doodads, and some kernel development experience, as well as general C experience, but I'm not by any means an expert on the matter. Cheers, Elizabeth Myers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
Would it make sense to have a generic 'backlight' driver framework that we plug into? I wrote a backlight driver (well, 2, but both show up as dev.backlight in sysctl) for powerpc, but if we want to have even more individual backlight drivers, I think it makes sense to make them all look the same, with similar configuration properties. - Justin On Fri, Jan 30, 2015 at 3:16 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, Which chipset is it? Loading acpi_video causes a handful of interconnected pieces to shift (as IIRC at that point acpi_video also states that it wishes to take control of video setting, not just leave it all up to ACPI to drive itself.) There's a bunch of discussion / code churn in the linux dri2/i915 code (/past/ the point in 2012 that our code is currently synced to) about how to manage backlights. A lot of it seems due to ridiculously large variations in how backlights are actually managed. So, if we're going to do this, I think we should actually have a generic backlight thing that figures out if the right thing to do is talk to the underlying device/panel, rather than hang backlight controls off of each driver. It may not always be off of drm. :( There's also stuff surrounding locking and state changes, as well as restoring backlight values after a suspend/resume cycle. That kind of weird crap. But I'd start with which chipset it is, which version of FreeBSD it is, and whether the ACPI stuff would work for you with a code update. But for a more general future thing, I'd rather we had a sysctl tree of actual display devices, each one mapping to the underlying thing it's controlling, so it's a generic API for both getting and setting values for the various displays that are hooked into things. -adrian On 27 January 2015 at 22:38, Elizabeth Myers elizab...@interlinked.me wrote: Hello, I want to add backlight support to the i915 driver in FreeBSD. It seems that two magic addresses are read and wrote from to change the backlight itself. It supports rather fine-level granularity all the way down to zero. Right now I use a hacked-up userland program that reads from/writes to these addresses, which is far from an ideal solution. I am interested in this because the acpi_video(4) driver does not support my backlight on my Dell Inspiron 15 3521 (not terribly suprising, on Linux I needed a special Dell-specific driver, and I'm not sure even that really used ACPI, I never really checked). My questions are really twofold: 1) How can this be exposed appropriately? I would prefer this be exposed generally so upower could grok it. As far as I can tell upower uses hw.acpi.video.lcd0 to control backlight. I am not sure that upower is doing the right thing here, though. 2) Where would the code go for this? The dri2 driver seems the most logical place, but maybe it belongs in X and exposed via a program? Or something else entirely that I'm not thinking of? I have experience developing PCI drivers and doing other PCI related doodads, and some kernel development experience, as well as general C experience, but I'm not by any means an expert on the matter. Cheers, Elizabeth Myers ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On Friday, January 30, 2015 04:45:45 PM Elizabeth Myers wrote: On 01/30/15 09:17, John Baldwin wrote: Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) I'm wondering if that's the correct place for it to live. So far it's the only real place it *can* live that makes logical sense imho, unless anyone has better ideas. This is awesome. As for upower, it should probably be patched to know about other types of brightness sysctls if/when this is implemented. For now I think hanging it off of the device_t is fine. It can be moved later if there is an urgent need. However, I suspect that tools like upower will need updating regardless of where it ends up living. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 30 January 2015 at 17:01, Elizabeth Myers elizab...@interlinked.me wrote: On 01/30/15 17:45, John Baldwin wrote: On Friday, January 30, 2015 04:45:45 PM Elizabeth Myers wrote: On 01/30/15 09:17, John Baldwin wrote: Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) I'm wondering if that's the correct place for it to live. So far it's the only real place it *can* live that makes logical sense imho, unless anyone has better ideas. This is awesome. As for upower, it should probably be patched to know about other types of brightness sysctls if/when this is implemented. For now I think hanging it off of the device_t is fine. It can be moved later if there is an urgent need. However, I suspect that tools like upower will need updating regardless of where it ends up living. Now a more interesting question... the raw PCM backlight value used by the hardware means that one can set the backlight to anything between 0 and a specific number. On my system, it's 4882, and yes, there is a subtle difference between the values. Is it best to expose this as a percentage, or just have a read-only sysctl for max values? So, this is one of the discussions that popped up in the linux side of things, that we will end up eventually pulling into freebsd when the i915 code is updated. The raw value is (a) different per setup, and (b) may be inverted to work correctly. I also don't know if linear values along that spectrum map to linear brightness levels. So yeah, my suggestion we expose an ACPI/acpi_video like list of valid percentages, and let the user set them from 0-100%. That way the details of how the actual backlight values get derived are hidden from userland. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 19:31, Adrian Chadd wrote:
So, this is one of the discussions that popped up in the linux side of
things, that we will end up eventually pulling into freebsd when the
i915 code is updated.
The raw value is (a) different per setup, and (b) may be inverted to
work correctly.
I also don't know if linear values along that spectrum map to linear
brightness levels.
So yeah, my suggestion we expose an ACPI/acpi_video like list of valid
percentages, and let the user set them from 0-100%. That way the
details of how the actual backlight values get derived are hidden from
userland.
-adrian
I have a sort of rough draft of this. I've tested all the percentages
(Ivy Bridge) and they do seem to correlate linearly (and to the
intel_backlight userland program used by a lot of people). I haven't
been able to test on any other hardware as I don't have it, and I don't
know what chipsets require the value to be inverted, so I've not
implemented that.
If anyone else would like to help test, it'd be nice.
--
Cheers,
Elizabeth
Index: i915/i915_debug.c
===
--- i915/i915_debug.c (revision 277875)
+++ i915/i915_debug.c (working copy)
@@ -724,7 +724,7 @@
for (i = 0; i DRM_ARRAY_SIZE(error-ring); i++) {
struct drm_i915_error_object *obj;
-
+
if ((obj = error-ring[i].batchbuffer)) {
sbuf_printf(m, %s --- gtt_offset = 0x%08x\n,
dev_priv-rings[i].name,
@@ -1590,6 +1590,38 @@
return (0);
}
+// NB - only works when y != 0!
+#define U_CEIL_DIV(x, y) ((x) + (y) - 1) / (y)
+
+static int
+i915_backlight(SYSCTL_HANDLER_ARGS)
+{
+ struct drm_device *dev;
+ drm_i915_private_t *dev_priv;
+ int error;
+ u32 val, max;
+
+ dev = arg1;
+ dev_priv = dev-dev_private;
+ if(dev_priv == NULL)
+ return (EBUSY);
+ DRM_LOCK(dev);
+ val = intel_panel_get_backlight(dev);
+ max = intel_panel_get_max_backlight(dev);
+ DRM_UNLOCK(dev);
+
+ // XXX specific devices, works fine on ivy bridge though
+ val = (val * 100) / max;
+ error = sysctl_handle_int(oidp, val, 0, req);
+ if (error || !req-newptr)
+ return (error);
+ val = U_CEIL_DIV(max * val, 100);
+ DRM_LOCK(dev);
+ intel_panel_set_backlight(dev, val);
+ DRM_UNLOCK(dev);
+ return (0);
+}
+
static struct i915_info_sysctl_list {
const char *name;
int (*ptr)(struct drm_device *dev, struct sbuf *m, void *data);
@@ -1753,6 +1785,11 @@
CTLFLAG_RW, i915_intr_pf, 0, NULL);
if (oid == NULL)
return (ENOMEM);
+ oid = SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(top), OID_AUTO,
+ i915_backlight, CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_MPSAFE, dev,
+ 0, i915_backlight, I, NULL);
+ if (oid == NULL)
+ return (ENOMEM);
error = drm_add_busid_modesetting(dev, ctx, top);
if (error != 0)
@@ -1764,6 +1801,5 @@
void
i915_sysctl_cleanup(struct drm_device *dev)
{
-
free(dev-sysctl_private, DRM_MEM_DRIVER);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 30 January 2015 at 20:19, Elizabeth Myers elizab...@interlinked.me wrote: On 01/30/15 17:25, Justin Hibbits wrote: Would it make sense to have a generic 'backlight' driver framework that we plug into? I wrote a backlight driver (well, 2, but both show up as dev.backlight in sysctl) for powerpc, but if we want to have even more individual backlight drivers, I think it makes sense to make them all look the same, with similar configuration properties. - Justin I was thinking the same thing myself. There's a lot of different backlights out there, and acpi_video(4) obviously can't cover them all, which seems to define the de facto standard MIB for brightness sysctls (which upower presently uses). I hate to bikeshed, but I would humbly suggest adding an MIB hierarchy such as hw.backlight.hw_type.backlight_no.brightness (and maybe brightness_raw for advanced users who want/need more control). Woo! A patch! I'm happy with this, but you'll want to cc: kib at least who looks after the i915 code. Hi kib! I think this is fine for the short term and lets us experiment without committing to a fully public API for this for the short term. Do you have brightness buttons anywhere? What happens when you set it through this API and then you use the backlight buttons? -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 17:25, Justin Hibbits wrote: Would it make sense to have a generic 'backlight' driver framework that we plug into? I wrote a backlight driver (well, 2, but both show up as dev.backlight in sysctl) for powerpc, but if we want to have even more individual backlight drivers, I think it makes sense to make them all look the same, with similar configuration properties. - Justin I was thinking the same thing myself. There's a lot of different backlights out there, and acpi_video(4) obviously can't cover them all, which seems to define the de facto standard MIB for brightness sysctls (which upower presently uses). I hate to bikeshed, but I would humbly suggest adding an MIB hierarchy such as hw.backlight.hw_type.backlight_no.brightness (and maybe brightness_raw for advanced users who want/need more control). -- Cheers, Elizabeth ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 23:20, Adrian Chadd wrote: Do you have brightness buttons anywhere? What happens when you set it through this API and then you use the backlight buttons? I do, but FreeBSD doesn't have the needed WMI doodads to interact with this, nor do I have the needed Dell laptop doodads in the kernel to test otherwise. To get /those/ working will require something else entirely. I have been looking at the Linux drivers: https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-wmi.c https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-laptop.c I'll save those for another day though, this is a bit off-topic. If anyone else has laptop keys I'd like to see how they interact too. -- Cheers, Elizabeth ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 30 January 2015 at 22:13, Elizabeth Myers elizab...@interlinked.me wrote: On 01/30/15 23:20, Adrian Chadd wrote: Do you have brightness buttons anywhere? What happens when you set it through this API and then you use the backlight buttons? I do, but FreeBSD doesn't have the needed WMI doodads to interact with this, nor do I have the needed Dell laptop doodads in the kernel to test otherwise. To get /those/ working will require something else entirely. I have been looking at the Linux drivers: https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-wmi.c https://github.com/torvalds/linux/blob/master/drivers/platform/x86/dell-laptop.c I'll save those for another day though, this is a bit off-topic. If anyone else has laptop keys I'd like to see how they interact too. *nod* cool. I don't have any Dell hardware and I have no idea how any of that holds together. :( I'll wait and see what kib/jhb say and if there aren't any issues I'll commit your i915 debug patch. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Questions on adding backlight support for the i915 driver
On 01/30/15 17:45, John Baldwin wrote: On Friday, January 30, 2015 04:45:45 PM Elizabeth Myers wrote: On 01/30/15 09:17, John Baldwin wrote: Humm. If the code is going to live in the drm driver, then I would start with hanging a sysctl off of the drm device itself. (Each new-bus device_t has a sysctl ctx you can get to hang new nodes off of the device's node.) I'm wondering if that's the correct place for it to live. So far it's the only real place it *can* live that makes logical sense imho, unless anyone has better ideas. This is awesome. As for upower, it should probably be patched to know about other types of brightness sysctls if/when this is implemented. For now I think hanging it off of the device_t is fine. It can be moved later if there is an urgent need. However, I suspect that tools like upower will need updating regardless of where it ends up living. Now a more interesting question... the raw PCM backlight value used by the hardware means that one can set the backlight to anything between 0 and a specific number. On my system, it's 4882, and yes, there is a subtle difference between the values. Is it best to expose this as a percentage, or just have a read-only sysctl for max values? -- Cheers, Elizabeth ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
