On Wed, Feb 22, 2017 at 05:42:30PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 06:59:49PM +, Russell King - ARM Linux wrote:
> > On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > > This stuff should be using the clipped coordinates, not the user
> > > coordinates.
On Mon, Feb 20, 2017 at 06:59:49PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > This stuff should be using the clipped coordinates, not the user
> > coordinates. And it doesn't look like this guy is even calling the
> > clip helper
On Wed, Feb 22, 2017 at 03:15:42PM +, Liviu Dudau wrote:
> Hi Ville,
>
> On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> > > Hi Russell,
> > >
> > > On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM
Hi Ville,
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> > Hi Russell,
> >
> > On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote:
> > > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King -
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.
I don't have time to test right now, but it looks similar to
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.
>
> malidp seems to be calling that thing, but it still doesn't
> manage to
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Something I also noticed is this:
>
> scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> plane->state->crtc_y * plane->state->fb->pitches[0] +
> plane->state->crtc_x *
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> Hi Russell,
>
> On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > > Something I also noticed is this:
> > >
> > >
Hi Russell,
On Mon, Feb 20, 2017 at 12:16:03PM +, Russell King - ARM Linux wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > Something I also noticed is this:
> >
> > scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> >
On Mon, Nov 21, 2016 at 02:55:28PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 02:30:53PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> >
On Mon, Nov 21, 2016 at 06:23:24PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave
On Mon, Nov 21, 2016 at 06:16:16PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> >
On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > > > On Mon,
On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable. With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and
On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > > > On Mon,
On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > > > That is
On Mon, Nov 21, 2016 at 02:30:53PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > >
On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any
On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've
On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any
On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember
On Mon, Nov 21, 2016 at 12:25:56PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> > > I first noticed it when booting with the buggy I2C EDID reading, so
> > > DRM
On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
> > down, I
On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > > Hi,
> >
> > Hi Russell,
> >
> > >
> > > While testing HDMI with Xorg on
On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > Hi,
>
> Hi Russell,
>
> >
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up or shuts down, the display is shifted
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Hi,
Hi Russell,
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Hi,
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars are visible.)
>
Hi,
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many
28 matches
Mail list logo