Alan Coopersmith writes:
>> Signed-off-by: Adam Jackson
> Same code as http://patchwork.freedesktop.org/patch/39718/ but different
> comments. My r-b from
> http://lists.x.org/archives/xorg-devel/2015-January/045096.html
> applies to either set of comments.
Merged.
0829310..bb23fbf master
Alan Coopersmith writes:
> Hint that the current (XFree86 4.0 & later) version of the protocol
> is most common today.
I thought _X_UNLIKELY was to direct optimization? If so, it's hard to
see why we'd worry about that in this extension, unless you think
there's some documentation value here?
-
Maarten Lankhorst writes:
> libepoxy doesn't handle this case well, and tries to look for the
> glObjectLabel symbol in GLES2.
> As a result, using glObjectLabelKHR with opengl, or glObjectLabel with
> GLES will crash.
Let's get libepoxy fixed, instead of kludging around this in the
X server.
Vicente Olivert Riera writes:
> Making the cast to a pointer-sized integer, and then to a pointer fixes
> the problem.
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org devel
leave shadow_enable alone
>
> Signed-off-by: Jason Ekstrand
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
David Airlie writes:
>> As a DDX may declare offload support without supporting DRI2
>> (because it is using an alternative acceleration mechanism like DRI3),
>> when iterating the list of offload_source Screens to find a matching
>> DRI2 provider we need to check before assuming it is DRI2 capab
Alan Coopersmith writes:
> On 01/20/15 04:44 PM, Carlos Olmedo Escobar wrote:
>> Signed-off-by: Carlos Olmedo Escobar
>
> Reviewed-by: Alan Coopersmith
Merged.
437d2ec..f27d743 master -> master
--
-keith
signature.asc
Description: PGP signature
_
Dave Airlie writes:
> On 21 January 2015 at 19:22, Carlos Sánchez de La Lama
> wrote:
>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88614
>> Signed-off-by: Carlos Sánchez de La Lama
>
> Reviewed-by: Dave Airlie
Merged.
3d12941..437d2ec master -> master
--
-keith
signature.asc
Dave Airlie writes:
> From: Dave Airlie
>
> This adds glamor into the block handler call chain
> in the correct place.
>
> This should fix interactions between glamor and drivers
> requiring damage from glamor.
>
> v2: okay don't consolidate, just leave things wierd for now
> remove blcokhandler
Pierre Ossman writes:
> On Thu, 25 Dec 2014 13:55:13 -0800,
> Keith Packard wrote:
>
>> Pierre Ossman writes:
>>
>> > Please see the attached patch and see if this seems like a reasonable
>> > way to solve this. I thought about changing the BlockHandler
If the BlockHandler chain is modified while it is active (the only
time it can be modified), we need to re-fetch the current value and
store it in our private for use the next time through.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/driver.c | 1 +
1 file changed, 1
->BlockHandler(screen, timeout, readmask);
You'll need to add:
glamor_priv->saved_procs.block_handler = screen->BlockHandler
in case the block handler chain was modified during that call.
Otherwise, this is
Reviewed-by: Keith Packard
--
-keith
signature.asc
Descrip
Dave Airlie writes:
> From: Dave Airlie
>
> Some kernel drivers require notification that the frontbuffer
> has changed, so we add a damage collector and send the dirty
> rects in the block handler. It appears the glamor block
> handler was getting called after this one, leading to things
> gett
Markus Wick writes:
> glEGLImageTargetTexture2DOES only set the first level.
> Mesa handles this new texture as incomplete and renders a black screen.
> We also want to prevent linear filtering.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=81800
>
> Signed-off-by: Markus Wick
Merged.
5f2
Peter Hutterer writes:
> Olivier Fourdan (2):
> Fix subwindow in Xi emulated events
> Synchronize capslock in Xnest and Xephyr
Merged.
4e12d7b..5f2e8ac master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-dev
Pass the inverse of the texture size to glamor vertex shaders so that
we multiply by that instead of dividing by the size as multiplication
is generally faster than division.
Signed-off-by: Keith Packard
---
glamor/glamor_copy.c | 8
glamor/glamor_program.c | 16
Markus Wick writes:
> Yeah, I did wrote it. But meanwhile, I'd remove the MAX_LEVEL parameter
> as this isn't allowed in gl es.
Please send an updated patch containing the bits you want, along with a
Signed-off-by: line and we'll review it, merging it if it looks good.
--
-keith
signature.a
Jason Ekstrand writes:
> Correction, we have two completely different concepts of "shadow fb" going
> on here. One is the shadow from miext/shadow that seems to cover the
> entire screen pixmap. The other shadow buffers, the ones used for
> rotation, should be per-crtc. These two concepts of s
"Jasper St. Pierre" writes:
> Well, either MAX_LEVEL / BASE_LEVEL or MIN_FILTER / MAG_FILTER will
> fix it.
Well, we want to set the filters anyways, to avoid using LINEAR, which
can end up blending just a little bit due to rounding issues. But,
setting MAX_LEVEL might well help some drivers, so
"Jasper St. Pierre" writes:
> I guess I should follow up with that I don't really care how the patch ends
> up or which six colors of the bikeshed we end up choosing. I just want you
> to be aware of why that patch fixes the bug, why Eric is saying that we
> don't need MAX_LEVEL, and why GL is su
Keith Packard writes:
>> It's unknown why the X server does this by default, but turn it off.
> Reviewed-by: Keith Packard
Merged.
b058dec..4e12d7b master -> master
--
-keith
signature.asc
Description: PGP signature
_
Axel Davy writes:
> Actually we went up with a solution, the final patch wasn't sent to ml
> for a reason
> I don't know or remember.
>
> Recently someone else complaint of the bug and I linked him to a
> preliminary patch we had,
> and it fixed it for him.
> The preliminary patch was
> http:/
Michel Dänzer writes:
> On 05.01.2015 10:35, Keith Packard wrote:
>>
>> Ok, it's (almost) the first working day of the year, and we're supposed
>> to be shipping 1.17. I think we're quite close, but I want to make sure
>> everyone is ready for the
"Jasper St. Pierre" writes:
> Fine by me. I actually stopped using vrefresh in my kernel driver and
> instead started using drm_mode_vrefresh, so we can actually drop this
> patch.
Oh, we should send the correct vrefresh value to the kernel; it's part
of the API after all. Having an integer vref
"Jasper St. Pierre" writes:
> Because several functions do not properly fill in mode->VRefresh. A simple
> example is xf86RandRModeConvert. I figured it would be easier when we fill
> in vrefresh rather than fill all callers.
Sounds like we should just remove VRefresh then and compute it
everywh
"Jasper St. Pierre" writes:
> The kernel might want this information during modesetting.
> ---
> hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmod
,
> + "Couldn't allocate shadow pixmap for rotated CRTC\n");
> +return NULL;
This error path will need to free the shadow data, if that was allocated
as a part of this function.
The rest of this patch has been
Reviewed-by: Keith Packard
--
-ke
Jason Ekstrand writes:
> ---
> hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +++
> 1 file changed, 11 insertions(+)
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.o
Adam Jackson writes:
> On Mon, 2015-01-05 at 13:54 -0800, Alan Coopersmith wrote:
>> Same code as http://patchwork.freedesktop.org/patch/39718/ but different
>> comments. My r-b from
>> http://lists.x.org/archives/xorg-devel/2015-January/045096.html
>> applies to either set of comments.
>
> Tsk,
Jason Ekstrand writes:
> This way all of the buffer allocation/destruction is in the same file.
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: h
FPS.
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
see the old shadow_bo getting freed anywhere; did I miss
something?
The rest of this patch looks good and is
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
(ScreenPtr pScreen, int argc, char **argv)
> if (!ms->drmmode.sw_cursor)
> xf86_cursors_init(pScreen, ms->cursor_width, ms->cursor_height,
>HARDWARE_CURSOR_SOURCE_MASK_INTERLEAVE_64 |
> + HARDWARE_CURSOR_
ndle_new_screen_pixmap so that glamor_set_screen_pixmap
>only gets called for the screen pixmap
> - Guard the call to glamor_set_screen_pixmapa with a drmmode->glamor
> check
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
Vicente Olivert Riera writes:
> Making the cast to a pointer-sized integer, and then to a pointer fixes
> the problem.
> -if (dladdr((void *)(pip.start_ip + off), &dlinfo) &&
> dlinfo.dli_fname &&
> +if (dladdr((void *)(long)(pip.start_ip + off), &dlinfo) &&
> dlinfo.dli_fname
Jason Ekstrand writes:
> Turns out that our trip down the rabbit hole today about the dumb_bo.pitch
> parameter was a red hering. That was in bytes the entire time. The actual
> bug was that I was passing cpp rather than bpp into drmmode_create_bo.
Awesome! Glad you figured it out.
>
> If you'
Aaron Plattner writes:
> I mentioned it on IRC but I should probably say it here too for the
> record: I don't think this should go into 1.17. It's a big enough
> change in behavior that some soak time on master is probably warranted.
> We can always backport it to server-1.17-branch later
Alan Coopersmith writes:
> Is the change discussed on IRC to change the default from --disable-glamor
> to enabling if PKG_CHECK_MODULES(epoxy) slated for 1.18 as well, since it's
> a bit late to change for 1.17?
Yes, I think changing the default build can wait; anyone who wants to
include it in
Peter Hutterer writes:
> On Mon, Jan 05, 2015 at 12:54:28PM -0800, Eric Anholt wrote:
>> Peter Hutterer writes:
>>
>> > Reported-by: Adam Greenblatt
>> > Signed-off-by: Peter Hutterer
>>
>> Seems pretty obvious.
>>
>> Reviewed-by: Eric Anholt
>
> Thanks!
>
> Keith, can you merge this one d
Peter Hutterer writes:
>> Signed-off-by: Keith Packard
>
> Reviewed-by: Peter Hutterer
Merged.
1c01633..23a11fd master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
n updated patch which fixes those, and filters xmlto
output even harder so that it now generates no output in the normal case
for me.
From 6ac3a081f5fbe38eeb9fe6d92efe3111e6dc4a77 Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Sun, 4 Jan 2015 19:13:35 -0800
Subject: [PATCH] doc: Create a script t
Kenneth Graunke writes:
> That's true. I should probably just resurrect your Xephyr VAO patch, and
> extend it for the rest of Glamor as well.
Yeah, would be good as that's required for 3.0 core context
support. Note that most of the VAO work is actually in the Render
extension drawing code, an
This reduces the build log spam while still preserving the xmlto
status to catch build failures correctly.
Signed-off-by: Keith Packard
---
devbook.am | 10 ++
doc/filter-xmlto | 17 +
2 files changed, 23 insertions(+), 4 deletions(-)
create mode 100755 doc/filter
Ok, it's (almost) the first working day of the year, and we're supposed
to be shipping 1.17. I think we're quite close, but I want to make sure
everyone is ready for the release before it happens.
From my list of pending patches, we've got:
glamor:
some optimizations for lighter-weight h
Keith Packard writes:
> Peter Hutterer writes:
>
>> I wonder if we've reached the point where having a small shell script to
>> build
>> this with the reduced output is easier than stuffing this into makefile
>> rules...
>
> Could be. This just seemed
Adam Jackson writes:
> Adam Jackson (2):
> glx: Dynamically compute attribute slot in GetDrawableAttributes
> glx: Add hack for GLX-1.2-style naked windows to GetDrawableAttributes
Merged.
3573855..1c01633 master -> master
--
-keith
signature.asc
Description: PGP signature
__
Peter Hutterer writes:
> Reviewed-by: Peter Hutterer
Merged.
de89c6b..3573855 master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
In
Eric Anholt writes:
> I think this will break glamor_xv.c and Xephyr, but I'm definitely in
> favor of just making those explicitly bind their VBO state instead (or
> maybe just use the same VBO if we can).
I think we're going to rework a bunch of this code when we switch to
vertex arrays anyway
Peter Hutterer writes:
> Peter Hutterer (2):
> dix: offset touch root coordinates by ScreenRec origins (#86655)
> xfree86: rename Xorg.bin to Xorg
Merged.
dc777c3..de89c6b master -> master
--
-keith
signature.asc
Description: PGP signature
Kenneth Graunke writes:
> I remember commenting about this to Keith at one point, and I seem to recall
> him preferring idempotency - each operation alters some state, then puts it
> back when it's done. Except that we're really just mashing it on then
> mashing
> it off, not saving/restorin
Alan Coopersmith writes:
> Reviewed-by: Alan Coopersmith
Merged.
924996c..dc777c3 master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-deve
Rob Clark writes:
> hmm, what minimum gl and gles version do we need to expose instanced
> drawing? Or any other useful extensions that glamor could use? Not
> sure if that would make a difference between gl vs gles?
We use instanced drawing on anything with GLSL version 1.30 or later.
As fo
The length checking code validates PutImage height and byte width by
making sure that byte-width >= INT32_MAX / height. If height is zero,
this generates a divide by zero exception. Allow zero height requests
explicitly, bypassing the INT32_MAX check.
Signed-off-by: Keith Packard
---
Rob Clark writes:
> well, adreno doesn't do native quads, and I think vc4 doesn't
> either... so an alternative path is useful. Perhaps we should cook up
> an extension to indicate that quads are emulated if just avoiding
> quads across the board is not a good option for some hw...
Would GLES j
Eric Anholt writes:
>> Reviewed-by: Adam Jackson
>> Signed-off-by: Michele Baldessari
>
> Reviewed-by: Eric Anholt
Merged.
7b076fd..924996c master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org
Carl Worth writes:
> I'm interested in copying this code to the mesa project, but before
> doing that it seems prudent to have the license and copyright
> attributions in place before copying that. To get this list of names I
> went through:
>
> git log -- os/xsha1.c
> and:
> git log
"Jasper St. Pierre" writes:
> On a UMA system, that's effectively free. With a triangle fan and
> glMultiDrawElements, you can get it down to four, same as a quad. Though
> I'm not sure if mesa fully supports glMultiDrawElements.
>
> I believe mesa supports primitive reset, so with a triangle fan
Rob Clark writes:
> What about simply not using GL_QUADS for the normal GL paths? Is
> using quads, vs tri's and a few extra vertices really going to be a
> win on some other hw? If not, avoiding quads would be a big help for
> freedreno too..
Without quads, you end up replicating a lot of ver
Rob Clark writes:
> Reviewed-by: Rob Clark
Merged.
d723928..6672606 master -> master
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http:/
the original patch.
From f8d1142238a8fe2f274aaeba25484c84f26aaf81 Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Mon, 29 Dec 2014 14:34:11 -0800
Subject: [PATCH] os: Fix warnings in timer patch
---
os/WaitFor.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a
> Keith, any chance of getting this in for 1.17? I know you expressed
> reservations about it, but the current code definitely corrupts the
> timer list and is affecting a bunch of people, so this patch is
> certainly better than nothing.
Yeah, it's an ugly little bit of code, and still seems
Peter Hutterer writes:
> Haven't sent one yet, I wanted to wait for Hans' ack/nak on this, but with
> the holiday period atm it'll take a few more days. I'll send out the pull
> after that.
Ok, just checking. I'd like to wrap up 1.17 before I take off for LCA if
possible; not sure what else you
Eric Anholt writes:
> Reviewed-by: Eric Anholt
Merged.
09230a2..d723928 master -> master
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xo
Kertesz Laszlo writes:
> Tried it and it works. I had a ~10 min Skype call and had no issues.
Thanks for testing.
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lis
Eric Anholt writes:
>> --- a/glamor/glamor_xv.c
>> +++ b/glamor/glamor_xv.c
>> @@ -435,7 +435,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
>> }
>>
>> top = (src_y) & ~1;
>> -nlines = (src_y + height) - top;
>> +nlines = (src_y + src_h) - top;
>>
>> switch (i
ew only a subset of the
image. I think the client is drawing at src_y=1, src_h=239 for some
weird reason (I suspect a bug in the client).
Try this patch:
From eaa4225413b31314070f9a52d9290649e79a3b0f Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Sat, 27 Dec 2014 09:11:33 -0800
Subject: [PATC
Michel Dänzer writes:
> One possible reason is that in contrast to the M9000, the HD5450 doesn't
> have a dedicated 2D engine which can do overlapping blits. It has to
> emulate those using two copies via a temporary pixmap.
If the difference is glamor vs custom 2d code, then the problem is
almo
Peter Hutterer writes:
> true, both changed locally
Did I miss a patch/pull request with this change included?
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.
Peter Hutterer writes:
> Nothing was using it and if anyone had they would've gotten a warning and
> noticed that it doesn't actually work. Drop this, it has been unused for
> years.
>
> Input ABI 22
Seems reasonable to fix the API for this, but the patch will need to
wait until after 1.17 is r
Pierre Ossman writes:
> Please see the attached patch and see if this seems like a reasonable
> way to solve this. I thought about changing the BlockHandlerProc
> definition, but it is exposed in application headers so it didn't seem
> safe to touch.
I think we should just change the BlockHandle
Jason Ekstrand writes:
> -glamor_set_screen_pixmap(screen_pixmap, NULL);
> +glamor_set_screen_pixmap(pixmap, NULL);
This call is only valid for the screen pixmap. We need to fix the glamor
APIs (I've posted a long blog article about this, and have a patch
sequence proposed already).
--
Jason Ekstrand writes:
> Signed-off-by: Jason Ekstrand
We probably only want to use a gbm buffer if we're using glamor;
otherwise, it's possible we'll get potentially slow video memory for our
software rendering path, and that would defeat most of the reason for
using a shadow frame buffer.
--
symmetrical with
drmmode_create_initial_bos and fetch the Screen from the ScrnInfo with
xf86ScrnToScreen.
Otherwise, this patch is
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org:
Keith Packard writes:
> Kenneth Graunke writes:
>
>> Previously, if present_queue_vblank() failed, we simply dropped the
>> present request on the floor, and returned an error. This was rather
>> mean to clients - after presenting, they wait for a PresentComplete
>
Peter Hutterer writes:
> On Mon, Dec 22, 2014 at 11:35:29AM -0800, Dima Ryazanov wrote:
>> Currently, the indexes are off by 4 because of the scroll buttons.
>>
>> Signed-off-by: Dima Ryazanov
>
> Reviewed-by: Peter Hutterer
Merged.
70a6f65..f9e22ce master -> master
--
keith.pack...@int
Michel Dänzer writes:
> From: Michel Dänzer
>
> _glamor_upload_bits_to_pixmap_texture currently ignores the stride
> parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
> via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).
>
> Also fix up the stride argument passed in though, in case i
Michel Dänzer writes:
> Fixing Debian bug report address.
Merged.
0d37c7e..11b85ab master -> master
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/a
Jason Ekstrand writes:
> Reviewed-by: Jason Ekstrand
Merged.
826e7c2..0d37c7e master -> master
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archi
you want to stick probes.h in include instead
of dix so you don't have a relative include in os/connection.c? I'm
easy, it's just a suggestion.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
Jamey Sharp writes:
> We've talked about doing the xserver equivalent of XCB for years--that is,
> auto-generating the protocol serialization and deserialization code from
> XCB's machine-readable descriptions of the X protocol and extensions.
>
> Considering the recent CVEs in that code, I think
Jason Ekstrand writes:
>> +if (err != -EINVAL && err != -ENOSYS) {
>
> I'm not terribly familiar with the ioctls here, but why are we ignoring
> EINVAL? The previous patch made it sound like ENOSYS was the "I don't
> support this" error and EINVAL was a genuine error.
We're treating EINVAL
The modesetting driver has support for informing the kernel driver
about all dirty regions of the screen. Frame buffer drivers like
DisplayLink use this to minimize the amount of data sent over the link
when things change.
Most other framebuffer drivers don't need (or want) this.
The first patch
Call drmModeDirtyFB and check the return value to detect whether the
driver support for damage tracking is present, only initialize it in
that case.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/driver.c | 27 ---
1 file changed, 16 insertions(+), 11
n and let dispatch_dirty
deal with them.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/driver.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/drivers/modesetting/driver.c
index d9a2982..59
xtensionInit() in dmx.c
Yeah, Rémi is right, i/j/k are terrible index variable names, but I've
also read through all of these and they look good to me.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
Alan Coopersmith writes:
> Gets rid of gcc 4.8 warnings:
> xf86AutoConfig.c:211:9: warning: nested extern declaration of
> 'xf86SolarisFbDev' [-Wnested-externs]
> sun_VTsw.c:44:1: warning: no previous prototype for 'xf86VTRelease'
> [-Wmissing-prototypes]
> sun_VTsw.c:59:1: warning: no pre
Alan Coopersmith writes:
> dtrace generates these as taking non const arguments, so cast away
> the constness of the pointers when calling them.
I really don't like casting away const. I note that Xserver-dtrace.h.in
is in git, so you could (?) add the const there instead?
--
keith.pack...@int
Alex Deucher writes:
> On Sun, Dec 14, 2014 at 1:29 AM, Keith Packard wrote:
>> This just calls the existing function to create the relevant Xv
>> adaptor and hook it up.
>>
>> Signed-off-by: Keith Packard
>
> Reviewed-by: Alex Deucher
Merged.
5
ust
> enough to not lock up people's compositing manager when vblank bugs
> happen.
>
> v2: Don't do present_queue_vblank() /and/ present_execute() (a bug that
> snuck in during last minute tidying).
With this replacement for the previous patch, the whole series is
Revi
, "%s: Failed to execute %s/Xorg: %s\n",
> progname, SUID_WRAPPER_DIR, strerror(errno));
> exit(1);
This could be simplified to just use the computed name in the two
locations that print it out?
Otherwise, this change is r
Michel Dänzer writes:
> Opening curly brace goes on separate line.
>
> With that fixed,
>
> Reviewed-by: Michel Dänzer
Merged.
0f5fdaf..5a541bd master -> master
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel
Michel Dänzer writes:
> Opening curly brace goes on separate line.
Too much java in my life, clearly.
> With that fixed,
>
> Reviewed-by: Michel Dänzer
Thanks!.
--
keith.pack...@intel.com
signature.asc
Description: PGP signature
___
xorg-devel@l
displayed.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 76 +---
hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
2 files changed, 41 insertions(+), 36 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/
Michel Dänzer writes:
> I don't think there's any guarantee that the new cursor image will
> become visible without calling drmModeSetCursor(2), so this solution
> won't work in general (e.g. with virtual hardware). Instead, you need to
> remember whether or not the cursor is currently visible, a
drmmode_show_cursor.
Signed-off-by: Keith Packard
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 30 ++--
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index
Mario Kleiner writes:
> It's just that i need access to both, the old behaviour i described, and
> the new "drop frame" behaviour, and i need a way to select what i want
> at runtime via api without the need for easily overwhelmed and confused
> users to change config files or environment vari
Mario Kleiner writes:
> Hmm. For benchmarking i think i'd consider that a mild form of cheating.
> You get higher fps because you skip processing like the whole gpu blit
> overhead and host processing overhead for queuing / validating /
> processing the copy command in the command stream, so t
Mario Kleiner writes:
> The 0 case is good for benchmarking.
Sure, but the current code does benchmarking just fine. In fact, because
it doesn't copy queued frames that aren't the most recent before the
vblank, benchmarks tend to run *faster* as a result, and people
generally like that aspect of
Kenneth Graunke writes:
> On Friday, December 12, 2014 02:21:57 PM Jason Ekstrand wrote:
>> Another note: With this patch, I had an issue that, when it woke my monitor
>> up after a lock, it was entirely black + cursor. VT switching didn't
>> help. I killed gnome shell and, when I came back thi
Mario Kleiner writes:
> Restores proper immediate tearing swap behaviour for
> OpenGL bufferswap under DRI3/Present.
Hrm. I'd love for this to be controlled by the GLX_EXT_swap_control_tear
extension, but that one uses negative interval values to indicate
tearing, instead of providing a new API,
1201 - 1300 of 5022 matches
Mail list logo
