From owner-freebsd-current@FreeBSD.ORG Sat Jan 31 03:59:21 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C178148F for ; Sat, 31 Jan 2015 03:59:21 +0000 (UTC) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.99.209.192]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "mail.wilcox-tech.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 71D02323 for ; Sat, 31 Jan 2015 03:59:20 +0000 (UTC) Received: (qmail 6594 invoked from network); 31 Jan 2015 04:00:37 -0000 Received: from ip68-13-243-137.ok.ok.cox.net (HELO ?192.168.1.253?) (emyers@wilcox-tech.com@68.13.243.137) by mail.foxkit.us with ESMTPA; 31 Jan 2015 04:00:37 -0000 Message-ID: <54CC5311.9070604@interlinked.me> Date: Fri, 30 Jan 2015 21:59:13 -0600 From: Elizabeth Myers User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Questions on adding backlight support for the i915 driver References: <54C883E7.4000300@interlinked.me> <54CBA0A4.30708@FreeBSD.org> <54CC0999.90500@interlinked.me> <3595567.zVLW9tlg0N@ralph.baldwin.cx> <54CC2981.3040909@interlinked.me> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000605020202050401070404" Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 03:59:21 -0000 This is a multi-part message in MIME format. --------------000605020202050401070404 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 --------------000605020202050401070404 Content-Type: text/x-patch; name="intel-i915-backlight.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="intel-i915-backlight.patch" 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); } --------------000605020202050401070404--