Hi
On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti
wrote:
> Do we have an agreement here after all? David? I need to know whether this
> fixup is okay to go cause I'll need to submit to Chrome OS then.
Sure it is fine. The code is already there, we cannot change it.
Thanks
David
___
Hi
On Wed, Mar 23, 2016 at 12:56 PM, Chris Wilson wrote:
> On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote:
>> My question was rather about why we do this? Semantics for EINTR are
>> well defined, and with SA_RESTART (default on linux) user-space can
>> ignore
Hey
On Mon, Mar 21, 2016 at 6:14 PM, Daniel Vetter wrote:
> On Mon, Mar 21, 2016 at 01:26:58PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter
>> wrote:
>> > Just a bit of wording polish plus mentioning that it
Hi
On Mon, Mar 21, 2016 at 8:51 AM, Daniel Vetter wrote:
> Just a bit of wording polish plus mentioning that it can fail and must
> be restarted.
>
> Requested by Sumit.
>
> v2: Fix them typos (Hans).
>
> Cc: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane M
Hi
On Fri, Jan 3, 2014 at 5:13 PM, Russell King - ARM Linux
wrote:
> On Fri, Jan 03, 2014 at 05:05:46PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jan 2, 2014 at 10:27 PM, Russell King
>> wrote:
>> > The encoder possible_crtcs mask identifies which CRT
o find mask for
> + *
> + * Given a registered CRTC, return the mask bit of that CRTC for an
> + * encoder's possible_crtcs field.
I think this is a nice cleanup which we could pick up right away. Most
drivers can be simplified by using this. Only the name is misleading,
imo, I&#x
Hi
On Thu, Dec 19, 2013 at 11:08 AM, David Herrmann wrote:
> Hi
>
> On Thu, Dec 19, 2013 at 10:59 AM, Jiri Kosina wrote:
>> On Thu, 19 Dec 2013, David Herrmann wrote:
>>
>>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>>> > inde
Hi
On Thu, Dec 19, 2013 at 10:59 AM, Jiri Kosina wrote:
> On Thu, 19 Dec 2013, David Herrmann wrote:
>
>> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> > index 253fe23..81eacd3 100644
>> > --- a/drivers/hid/hid-core.c
>> > +++ b/driv
Hi
On Mon, Dec 16, 2013 at 2:01 PM, Jiri Kosina wrote:
> On Fri, 27 Sep 2013, Joseph Salisbury wrote:
>
>> >> commit b1a1442a23776756b254b69786848a94d92445ba
>> >> Author: Jiri Kosina
>> >> Date: Mon Jun 3 11:27:48 2013 +0200
>> >>
>> >> HID: core: fix reporting of raw events
>> >>
>> >> Rev
Hi
On Sat, Aug 17, 2013 at 1:04 AM, Haiyang Zhang wrote:
>> > But I saw VESA VBE in the x log. Seems it's the default driver:
>> > "/var/log/Xorg.0.log":
>> > [12.340] (II) VESA(0): Primary V_BIOS segment is: 0xc000
>> > [12.341] (II) VESA(0): VESA BIOS detected
>> > [12.341] (II) VES
Hi
On Fri, Aug 16, 2013 at 10:27 PM, Haiyang Zhang wrote:
>
>
>> -Original Message-----
>> From: David Herrmann [mailto:dh.herrm...@gmail.com]
>> Sent: Friday, August 16, 2013 3:11 PM
>> To: Haiyang Zhang
>> Cc: linux-fb...@vger.kernel.org; driverdev-d
Hi
(hint: your mail header seems to drop Reference-to/Reply-to headers
and breaks thread-info)
On Fri, Aug 16, 2013 at 8:45 PM, Haiyang Zhang wrote:
>
>
>> -Original Message-----
>> From: David Herrmann [mailto:dh.herrm...@gmail.com]
>> Sent: Friday, August 16, 201
Hi
On Mon, Aug 5, 2013 at 9:12 PM, Haiyang Zhang wrote:
> Hi folks,
>
> I'm working on an issue of HyperV synthetic frame buffer driver, which seems
> to have
> a conflict with the generic vga driver (not the vesa driver). I hope to read
> and trace into
> the source code for the generic vga dr
13 matches
Mail list logo
