Re: libXO-ification - Why - and is it a symptom of deeper issues?

2015-11-16 Thread Elizabeth Myers 
On 15/11/15 06:54, Dan Partelly wrote:
> Hi all,
>
> I was looking at the new facility of dumping JSON,XML from many utils in base 
> and after some funny minutes, I couldn't stop ask myself “ Ok, this is funny 
> , but why ? “ And I couldn't find a real answer. Ill outline what I think:
>
>
> 1. Undoubtedly, it makes base code slightly harder to understand and 
> maintain. 
> 2. I have seen the idea that this makes the information dumped by utilities 
> in the base easily accessible programatically. OK, maybe it does , but
> it doesn't fit with the current paradigm of "tool | filter | tool” at all. 
> There are no tools able to accept JSON and filter it in any meaningful way, 
> and I
> dont see too many ppl changing their code to read JSON instead of text.  I 
> don't even see the base tools changing. This output may be useful in corner 
> cases only.
> 3. The integration of libxo IMO only points at a much deeper issue IMO. It is 
> only an expression of the need of a mechanism aimed at binary code reuse. But 
> it does not solve the problem, it only adds yet another possibility in a 
> world where too much choices already result in too much splits and 
> incompatible APIs. 
> 4. This whole effort would have been IMO much better served  by porting the 
> bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, much like 
> the libs for geom, zfs , etc , ready for reuse of 3rd party code. Eventually 
> writing network control daemons in time over it , much like solaris does.
>
> 5. A port of partial OS config data to UCL …. would induce yet induce another 
> orthogonality violation. What makes UCL better than the bestiary of ad hoc 
> databases already existing in BSDs ? Programatic readability, yes. but it 
> does not add any real much needed functionality such as *transactional 
> databases* for system tools.   Why not research a proper solution - easily 
> accessible by other programs ,orthogonal , transactional, and ACL protected   
> solution  which can be used all over the place , from OS boot, to ABI 
> management, service management, network management, user management.  I hope 
> this day will come, a day when I will not have to edit a single config file 
> manually, yet I would have access to all the config and system state  easy 
> with wrapper APIs. In the light of this point, why go with UCL ? It is not 
> orthogonal, it is not transnational, and editing the config files directly 
> would result in the same old human errors which bite as all from time to time.
>
> 5. It is my opinion that Solaris addressed some of those issue. Solaris FMRI 
> and SMF are lightyears ahead of the very tired models we keep using on BSDs. 
> Why not build on the insight offered by those (or even on the insight offered 
> by Windows :P) , then inventing more adhoc solutions and ad-hoc databases, 
> which do not address the real issues we have , like binary code reuse, 
> service management issues,  lack of a system wide published -subscriber bus ( 
> not kdbus :P ) fault detection and reaction, fault reporting, all much needed 
> parts of a modern OS. 
>
> And now thee questions
>
> 1. Why lib XO ? Why burden the OS for some corner cases where it may be 
> useful ?
>
> 2. Was there any real talk on how to bring FreeBSD up to speed regarding 
> those issues ?  A period of research on what exists, on what can be done , 
> and ensure important things are not showed in background and replaced with 
> yet another ad-hoc config database which lacks modern features ?
> From where I am standing, this could be a project spawning multiple years , 
> but it would be well worth it, and in my opinion it would be also worthy of 
> the freeSBD foundation sponsorship for several years in a row. The features I 
> touched upon became very important parts of oder OSes, and rightly so. 
>
> Note:
>
> this message is serious and it is not intended to start flame wars, religious 
> crusades, or offend anyone. 
>  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

It seems to boil down to the golden rule: he who has the gold, makes the
rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD
foundation and employ many devs, so they got their way.

That's all there is to it.

--
Regards,
Elizabeth Myers


___
freebsd-current@freebsd.org mailing list
https://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

2015-01-31 Thread Elizabeth Myers 
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

2015-01-31 Thread Elizabeth Myers 
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: drm2 regression: backlight adjustment on ivybridge no longer works

2015-01-31 Thread Elizabeth Myers 
On 01/31/15 02:00, Miguel Clara wrote:
 I had to patch manually, for some reason the diff was rejected, but I t
 compiled and I've instead on 10/stable... problem is this is the laptop
 where I am typing this :D
 
 Its also upgrading some ports, so not a good time to reboot, but I'll
 post results in the other thread, as for the HP, works perfect (for me
 at least... far better then what I had :) )

Good to know! If this gets merged (even in modified form), you could ask
about an MFC. I'm not the person to ask about this though, I'm just a
humble peon.

--
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

2015-01-30 Thread Elizabeth Myers 
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

2015-01-30 Thread Elizabeth Myers 
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

2015-01-30 Thread Elizabeth Myers 
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

2015-01-30 Thread Elizabeth Myers 
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: drm2 regression: backlight adjustment on ivybridge no longer works

2015-01-30 Thread Elizabeth Myers 
On 01/31/15 01:11, Miguel Clara wrote:
 On the laptop I'm running current, if relevant
 
 Loading acpi_video doesn't do much  I don't see any sysctl related to
 lcd0 or birightness, this is one of those computers with hybrid
 graphics, intel + ATI card, so not sure if that's somewhat related.
 
 
 Anyway, I've just tested the drm patches (both) and intelbacklight (
 https://github.com/grembo/intel_backlight_fbsd) compiles, installs and runs
 fine!
 
 So thanks both for the patches.

You might be interested in my newest patch to add backlight control to
sysctl. It's probably better for everyone (imo) that backlight control
is integrated into the driver and accessible via sysctl, so it works the
same way for everyone.

Look for the subject Re: Questions on adding backlight support for the
i915 driver from me and you'll find the patch. I am curious if it works
for you.

--
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: drm2 regression: backlight adjustment on ivybridge no longer works

2015-01-30 Thread Elizabeth Myers 
On 01/31/15 01:28, Miguel Clara wrote:
 I saw the discussion about how to approach the issue, but totally missed
 the patch :D
 
 Thanks, I'll try that... I'm assuming it will make no difference on
 10/stable yet? only current?

Excellent question! I have absolutely no idea. I don't even think it
applies cleanly. If you can get it to apply and it builds, it just might
work.

--
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

2015-01-30 Thread Elizabeth Myers 
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

Questions on adding backlight support for the i915 driver

2015-01-27 Thread Elizabeth Myers 
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