Re: [PATCH 6/9] drm: Add a DRM_CAP_STEREO_3D capability for SET_CAP ioctl

2013-09-13 Thread Joakim Plate
David Herrmann dh.herrmann at gmail.com writes: So just to be clear: Whenever a mode is present with 3D flags, it is also a valid non-3D mode? Is this guaranteed? Well.. Some HDTV's will when they receive a frame packed mode (1080*2+45=2205 pixels high) . Display just the top part. The

Re: [PATCH 7/9] drm/edid: Expose mandatory stereo modes for HDMI sinks

2013-09-13 Thread Joakim Plate
Damien Lespiau damien.lespiau at intel.com writes: +static const struct s3d_mandatory_mode s3d_mandatory_modes[] = { + { 1920, 1080, 24, 0, + DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }, + { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE, +

[i915] Backlight brighter since 3.9.0

2013-05-22 Thread Joakim Plate
Hi, > > 2013/5/20 Daniel Vetter ffwll.ch> > Yeah, this is a feature. HDMI has (for oddball backwards compat with > analog TV signals) a special mode which reduces the useable RGB value > range by chopping off about 10% at the bottom and top end. This results in > light colors getting brighter

Re: [i915] Backlight brighter since 3.9.0

2013-05-22 Thread Joakim Plate
Hi, 2013/5/20 Daniel Vetter daniel at ffwll.ch Yeah, this is a feature. HDMI has (for oddball backwards compat with analog TV signals) a special mode which reduces the useable RGB value range by chopping off about 10% at the bottom and top end. This results in light colors getting brighter

[PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

2013-05-10 Thread Joakim Plate
Ville Syrj?l? linux.intel.com> writes: > I think I'll defer on that one until we decide whether we want add > both 60Hz and 59.94HZ versions to the connector's mode list. Daniel > suggested we do it, but I disagree slightly since CEA-861 says that > monitors should only advertise one variant in

Re: [PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

2013-05-10 Thread Joakim Plate
Ville Syrjälä ville.syrjala at linux.intel.com writes: I think I'll defer on that one until we decide whether we want add both 60Hz and 59.94HZ versions to the connector's mode list. Daniel suggested we do it, but I disagree slightly since CEA-861 says that monitors should only advertise one

RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-14 Thread Joakim Plate
> > > > From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only > > issue is that changing it will break any app relying on it being REALTIME clock. > > > > App that rely on it being anything special are badly broken and i > don't think there is any such app. The

Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-14 Thread Joakim Plate
From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only issue is that changing it will break any app relying on it being REALTIME clock. App that rely on it being anything special are badly broken and i don't think there is any such app. The specification

RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-13 Thread Joakim Plate
Michel D?nzer daenzer.net> writes: > > > > > > From the GLX_OML_sync_control spec: > > > > > > The Unadjusted System Time (or UST) is a 64-bit monotonically > > > increasing counter [...] > > >

Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-13 Thread Joakim Plate
Michel Dänzer michel at daenzer.net writes: From the GLX_OML_sync_control spec: The Unadjusted System Time (or UST) is a 64-bit monotonically increasing counter [...] From what I can tell, it should be using: ktime_to_ns(ktime_get()) / 1000. Only issue is

RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-10 Thread Joakim Plate
Hi, I'm currently trying to make use of OML_sync_control extension to schedule presentation of video frames in xbmc. I've run into somewhat of a snag. It seem the spec doesn't specify what time the UST clock really is, nor can i find any mention of it elsewhere in docs. Code wise it seem to

RFC: Change OML_sync_control UST to CLOCK_MONOTONIC

2012-06-10 Thread Joakim Plate
Hi, I'm currently trying to make use of OML_sync_control extension to schedule presentation of video frames in xbmc. I've run into somewhat of a snag. It seem the spec doesn't specify what time the UST clock really is, nor can i find any mention of it elsewhere in docs. Code wise it seem to

[PATCH] drm_edid: support CEA video modes

2012-05-18 Thread Joakim Plate
Joakim Plate ecce.se> writes: > > Christian Schmidt digadd.de> writes: > > > > > TFT/plasma televisions and projectors have become commonplace, and so > > has the use of PCs to drive them. Add the video modes specified by an > > EDID's CEA extensi

Re: [PATCH] drm_edid: support CEA video modes

2012-05-18 Thread Joakim Plate
Joakim Plate elupus at ecce.se writes: Christian Schmidt schmidt at digadd.de writes: TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by an EDID's CEA extension to the mode database for a connector

[PATCH] drm_edid: support CEA video modes

2012-02-06 Thread Joakim Plate
Christian Schmidt digadd.de> writes: > > TFT/plasma televisions and projectors have become commonplace, and so > has the use of PCs to drive them. Add the video modes specified by an > EDID's CEA extension to the mode database for a connector. Hi, Looking over this i noticed that this patch

Re: [PATCH] drm_edid: support CEA video modes

2012-02-06 Thread Joakim Plate
Christian Schmidt schmidt at digadd.de writes: TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by an EDID's CEA extension to the mode database for a connector. Hi, Looking over this i noticed that this