Hi David,
On Fri, Jun 19, 2020 at 10:57:37AM +0900, David Stevens wrote:
> On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski
> wrote:
> >
> > Hi Michael,
> >
> > On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, May 26,
Hi Michael,
On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
> > vi
On Sat, 19 Aug 2017, Bhumika Goyal wrote:
> Make this const as it is only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> ---
> drivers/media/i
likely, but if you or
others strongly disagree - I won't insist :)
Whether or not you decide to accept this proposal you have my
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> ---
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/v4l2-mediabus.h| 183
iscussion from
time to time, unfortunately I don't have too much time for it now. But in
any case if this work is going to be used with imx-drm too, that should be
a good direction to take, I think.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
have been better to use and - if needed - extend them to cover any
deficiencies? Even though the implementation is currently located under
drivers/media/v4l2-code/ it's pretty generic and should be easily
transferable to a more generic location.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
y been a precedent:
http://www.mail-archive.com/linux-media at vger.kernel.org/msg56213.html
It hasn't been finalised yet though.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
eady been a precedent:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56213.html
It hasn't been finalised yet though.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
Hi Daniel
Sorry for a late reply.
On Tue, 18 Dec 2012, Daniel Vetter wrote:
> On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
> wrote:
> > Sorry, not sure what information is most appropriate here. GPU hangs from
> > time to time on this laptop, typically when
Hi Daniel
Sorry for a late reply.
On Tue, 18 Dec 2012, Daniel Vetter wrote:
> On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
> wrote:
> > Sorry, not sure what information is most appropriate here. GPU hangs from
> > time to time on this laptop, typically when
grade). Sometimes also the
X-server freezes and restarts with no errors in dmesg. Is it a known
problem?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
grade). Sometimes also the
X-server freezes and restarts with no errors in dmesg. Is it a known
problem?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On Fri, 5 Oct 2012, Stephen Warren wrote:
> On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
> > Hi Steffen
> >
> > Sorry for chiming in so late in the game, but I've long been wanting to
> > have a look at this and compare with what we do for V4L2, so, thi
On Fri, 5 Oct 2012, Stephen Warren wrote:
> On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote:
> > Hi Steffen
> >
> > Sorry for chiming in so late in the game, but I've long been wanting to
> > have a look at this and compare with what we do for V4L2, so, thi
On Fri, 5 Oct 2012, Hans Verkuil wrote:
> On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> > On Wed, 3 Oct 2012, Rob Herring wrote:
> >
> > > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > > Hi Rob
> > > >
On Wed, 3 Oct 2012, Rob Herring wrote:
> On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > Hi Rob
> >
> > On Tue, 2 Oct 2012, Rob Herring wrote:
> >
> >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a docum
On Fri, 5 Oct 2012, Hans Verkuil wrote:
> On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
> > On Wed, 3 Oct 2012, Rob Herring wrote:
> >
> > > On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > > > Hi Rob
> > > >
On Wed, 3 Oct 2012, Rob Herring wrote:
> On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
> > Hi Rob
> >
> > On Tue, 2 Oct 2012, Rob Herring wrote:
> >
> >> On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a docum
i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive? BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a "field-even-active"
integer property for it.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
i.e. of the board? Can the
same display controller on one board require interlaced data and on
another board - progressive? BTW, I'm not very familiar with display
interfaces, but for interlaced you probably sometimes use a field signal,
whose polarity you also want to specify here? We use a &quo
On Wed, 11 Jul 2012, Sascha Hauer wrote:
> Hi Guennadi,
>
> On Wed, Jul 11, 2012 at 10:34:54AM +0200, Guennadi Liakhovetski wrote:
> > Hi Sascha
> >
> > > +
> > > +Optional properties:
> > > + - width-mm, height-mm: Display dimensions in mm
&g
On Wed, 11 Jul 2012, Sascha Hauer wrote:
> Hi Guennadi,
>
> On Wed, Jul 11, 2012 at 10:34:54AM +0200, Guennadi Liakhovetski wrote:
> > Hi Sascha
> >
> > > +
> > > +Optional properties:
> > > + - width-mm, height-mm: Display dimensions in mm
&g
+ xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-margin = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
+ hsync-active = <1>;
> + };
> +
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
+ xres = <1920>;
> + yres = <1080>;
> + left-margin = <25>;
> + right-margin = <25>;
> + hsync-len = <25>;
> + lower-margin = <2>;
> + upper-m
CLONE context-creation mode.
Anyway, my tuppence to consider.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
include kernel cmdline video mode parsing here, afaik
> kms and fbdev are rather similar (won't work if they're too different,
> obviously).
This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
too:-) The goal was to (1) take into account driver's capabiliti
CLONE context-creation mode.
Anyway, my tuppence to consider.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
include kernel cmdline video mode parsing here, afaik
> kms and fbdev are rather similar (won't work if they're too different,
> obviously).
This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
too:-) The goal was to (1) take into account driver's capabiliti
ion: buggy applications are, well, buggy...
Actually, since in FOURCC mode we don't need any of
__u32 bits_per_pixel; /* guess what */
__u32 grayscale;/* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
so, we could put them all in the union for the case, if we need anything
else for the fourcc configuration in the future.
> I'd like to reach an agreement on the API, and implement it. I'm fine with
> either grayscale or nonstd to store the FOURCC (with a slight preference for
> grayscale), and with either a vmode flag or using the most significant byte
> of
> the grayscale/nonstd field to detect FOURCC mode. I believe FB_CAP_FOURCC (or
> something similar) is needed.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
ion: buggy applications are, well, buggy...
Actually, since in FOURCC mode we don't need any of
__u32 bits_per_pixel; /* guess what */
__u32 grayscale;/* != 0 Graylevels instead of colors */
struct fb_bitfield red; /* bitfield in fb mem if true color, */
struct fb_bitfield green; /* else only length is significant */
struct fb_bitfield blue;
struct fb_bitfield transp; /* transparency */
so, we could put them all in the union for the case, if we need anything
else for the fourcc configuration in the future.
> I'd like to reach an agreement on the API, and implement it. I'm fine with
> either grayscale or nonstd to store the FOURCC (with a slight preference for
> grayscale), and with either a vmode flag or using the most significant byte
> of
> the grayscale/nonstd field to detect FOURCC mode. I believe FB_CAP_FOURCC (or
> something similar) is needed.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ansfers using the newly
> API.
>
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
ansfers using the newly
> API.
>
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
ementations.
Thanks
Guennadi
> >
> This sounds good. If we can remove the DRM dependent portion to have a
> library-ized EDID code,
> That would be perfect. The main Intention to have a library is,
> Instead of having several different Implementation in kernel, all
> doing the same
ementations.
Thanks
Guennadi
> >
> This sounds good. If we can remove the DRM dependent portion to have a
> library-ized EDID code,
> That would be perfect. The main Intention to have a library is,
> Instead of having several different Implementation in kernel, all
> doing the sa
?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
36 matches
Mail list logo
