Re: ACPI thinkpad brightness regression

On Wed, Feb 10, 2016 at 07:10:41PM GMT, Martin Pieuchot wrote: > On 09/02/16(Tue) 21:06, Christian Weisgerber wrote: > > On 2016-02-09, Martin Pieuchot wrote: > > > > > Since brightness support has been added to acpithinkpad(4) I can easily > > > trigger a regression on my

Re: ACPI thinkpad brightness regression

On 16/02/16(Tue) 20:46, Mark Kettenis wrote: > > Date: Wed, 10 Feb 2016 20:10:41 +0100 > > From: Martin Pieuchot > > > > On 09/02/16(Tue) 21:06, Christian Weisgerber wrote: > > > On 2016-02-09, Martin Pieuchot wrote: > > > > > > > Since brightness support

Re: ACPI thinkpad brightness regression

Mark Kettenis: > Does the following diff work? No. (Thinkpad X230.) > Index: acpithinkpad.c > === > RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v > retrieving revision 1.51 > diff -u -p -r1.51 acpithinkpad.c > ---

Re: std::ifstream is broken on arm

Actually, I had forgotten to disable the stack protector, and guess what? Disabling it produces a working libstdc++, at least for that simple use case; I have not tried to build cmake. Therefore I suggest the following diff until someone with enough love for the utter crap known as `arm' comes

Re: pax(1) gets stuck in a loop creating intermediate directories

On Mon Feb 15, Philip Guenther wrote: > ...and since pax's tar format code only trims a single trailing slash, it > will loop even in that case if you add more than one trailing slash. > > Indeed, if you add more than one trailing slash in general then it'll > still hang despite your patch:

drm/mesa: blocking (infinite) poll(2) after suspend/resume

Very often when resuming my x220 running GNOME3 the gnome-shell(1) process gets stuck and only the mouse can move on the screen. The stack trace indicates that all the threads seem to be waiting inside poll(2) for a GL-related operation that's unclear to me. At this stage switching to a virtual