[PATCH 1/3] omap: Fix missing usage count decrease in OMAPDRI2DestroyBuffer

omi Valkeinen Signed-off-by: Tony Lindgren --- src/omap_dri2.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/omap_dri2.c b/src/omap_dri2.c --- a/src/omap_dri2.c +++ b/src/omap_dri2.c @@ -316,7 +316,11 @@ OMAPDRI2DestroyBuffer(DrawablePtr pDraw, DRI2BufferPtr b

[PATCHv2 0/3] xf86-video-omap fixes

Hi, Here's the v2 version of these with the last patch fixed to use the right connector names. Regards, Tony Tony Lindgren (3): omap: Fix missing usage count decrease in OMAPDRI2DestroyBuffer omap: Few fixes to build with musl omap: Add proper names for DSI, DPI and Virtual conne

[PATCH 2/3] omap: Few fixes to build with musl

es 3. Use standard __func__ instead of __FUNCTION__ Cc: Ivaylo Dimitrov Cc: Laurent Pinchart Cc: Matthijs van Duin Cc: Merlijn Wajer Cc: Rob Clark Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren --- src/omap_driver.c | 2 +- src/omap_driver.h | 6 +++--- src/omap_uti

[PATCH 3/3] omap: Add proper names for DSI, DPI and Virtual connectors

c: Matthijs van Duin Cc: Merlijn Wajer Cc: Rob Clark Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren --- src/drmmode_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/drmmode_display.c b/src/drmmode_display.c --- a/src/drmmode_display.c +++ b/src/dr

Re: [PATCH 3/3] omap: Add proper name for DSI output

* Rob Clark [200127 21:53]: > On Mon, Jan 27, 2020 at 1:43 PM Tony Lindgren wrote: > > * Rob Clark [200127 21:24]: > > > I *think* gitlab[1] merge merge requests are the preferred way to > > > submit patches these days. (But tbh I've not followed xorg-d

Re: [PATCH 3/3] omap: Add proper name for DSI output

map hw should create an > account on gitlab and get the necessary permissions to merge MRs (or > push via git cmdline) > > [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-omap OK yeah let's see if Tomi or Sebastian can do that. Also I noticed one issue below.. > On Su

[PATCH 1/3] omap: Fix missing usage count decrease in OMAPDRI2DestroyBuffer

we get a segfault after rotating an sgx accelerated opengl es app and then terminating it. Fixes: 0bdd370ab720 ("dri2: hold extra buffer ref during swap") Cc: Laurent Pinchart Cc: Matthijs van Duin Cc: Merlijn Wajer Cc: Rob Clark Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off

[PATCH 3/3] omap: Add proper name for DSI output

Otherwise xrandr shows the name as "Unkonwn16-1" instead of DSI-1. Presumably output 15 is also DSI as there are two instances. Cc: Laurent Pinchart Cc: Matthijs van Duin Cc: Merlijn Wajer Cc: Rob Clark Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren

[PATCH 2/3] omap: Few fixes to build with musl

es 3. Use standard __func__ instead of __FUNCTION__ Cc: Laurent Pinchart Cc: Matthijs van Duin Cc: Merlijn Wajer Cc: Rob Clark Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren --- src/omap_driver.c | 2 +- src/omap_driver.h | 6 +++--- src/omap_uti

Re: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

* Michel Dänzer [180706 07:48]: > On 2018-07-05 05:42 PM, Tony Lindgren wrote: > > Hi, > > > > * Michel Dänzer [180705 14:21]: > >> > >> This uses the same damage region for all framebuffers, which is > >> generally not correct for drmmod

Re: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

Hi, * Michel Dänzer [180705 14:21]: > > This uses the same damage region for all framebuffers, which is > generally not correct for drmmode_crtc->rotate_fb_id. The coordinate > offset, rotation and reflection need to be taken into account for that. Hmm OK. I thought we just need to refresh it w

[PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set

RandR shadow buffers") that inroduced rotate_fb_id. Let's fix this issue by going through all the displays. Cc: Hans De Goede Cc: Jason Ekstrand Cc: Keith Packard Cc: Laurent Pinchart Cc: Lyude Paul Cc: Sebastian Reichel Cc: Tomi Valkeinen Signed-off-by: Tony Lindgren --- Here&#x

Re: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

desktop.org/patch/203834/ Looks like it's missing the description, do you want me to resend it with the description below? Regards, Tony > On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote: > > Looks like drmModeDirtyFB() stopped working at some point and we now > > cal

Re: Grabbing modesetting ddx related patches for pull request

on the ML that I found which > need reviews: > > * "modesetting: Update fb_id from shadow allocate and destroy if not set" >from Tony Lindgren: >https://patchwork.freedesktop.org/patch/203834/ Thanks for picking this one up. And yes that's the improved ver

Re: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

* Keith Packard [180203 20:33]: > I think the right place to fix this is in dispatch_dirty_regions, which > should be walking the set of active CTRCs and damaging the appropriate > fb_id for each one? So is the following test patch at all along the lines you were thinking? I wonder if we should

Re: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

Hi, * Keith Packard [180203 20:33]: > Tony Lindgren writes: > > > Looks like drmModeDirtyFB() stopped working at some point and we now > > call it with fb_id of zero for rotated displays. This will stop displays > > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display

[PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

drmmode.fb_id: 0 fb_id: 0 dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0 dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0 drmmode_set_mode_major: drmmode->fb_id: 51 dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51 ... Cc: Hans De Goede Cc: Jason Ekstrand Cc: Laurent Pinchart Cc: Sebastian Reichel C