The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
v2: Drop #ifndefs around the other two defines.
Signed-off-by: Eric Anholt
---
hw/xfree86/parser/Makefile.am | 1 -
hw/xfree86/parser/scan.c
Keith Packard writes:
> [ Unknown signature status ]
> Eric Anholt writes:
>
>> The reason to think so is that the previous code had this weird stuff to
>> explicitly handle unaligned. I rip out the unaligned support in patch
>> 3, because I think it's not n
Keith Packard writes:
> [ Unknown signature status ]
> Eric Anholt writes:
>
>> #define swapll(x) do { \
>> +uint64_t temp; \
>> if (sizeof(*(x)) != 8) \
>> wrong_size(); \
>> -
it.
text data bssdec hexfilename
before: 2215167 51552 132016 2398735 249a0f hw/xfree86/Xorg
after: 2214919 51552 132016 2398487 249917 hw/xfree86/Xorg
Signed-off-by: Eric Anholt
---
include/misc.h | 15 +++
test/misc.c| 25
Peter noted a weirdness in my new bswap code, which could use some
tests to justify it.
Signed-off-by: Eric Anholt
Reviewed-by: Peter Hutterer
---
test/misc.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/test/misc.c b/test/misc.c
index
filename
before: 2240807 51552 132016 2424375 24fe37 hw/xfree86/Xorg
after: 2215167 51552 132016 2398735 249a0f hw/xfree86/Xorg
Signed-off-by: Eric Anholt
---
doc/Xserver-spec.xml | 2 +-
glx/glxbyteorder.h | 21
include/misc.h | 97
parser/scan.c was checking for #ifdef XCONFIGFILE and XCONFIGDIR and
defaulting to "xorg.conf", and "xorg.conf.d", so if you had changed
__XCONFIGFILE__ to anything else, it would have got out of sync.
Settle on the name without gratuitous underscores.
Signed
The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
Signed-off-by: Eric Anholt
---
hw/xfree86/parser/Makefile.am | 1 -
hw/xfree86/parser/scan.c | 15 ---
xkb/ddxLoad.c
he Xserver. This affects Xwayland, Xephyr, modesetting driver
> with glamor accel.
>
> But the use of an FBO is not actually needed for glamox-xv, so by
> disabling FBO at pixmap creation, we can avoid the issue entirely.
>
> Fix suggested by Eric Anholt
>
> Signed-off-b
Olivier Fourdan writes:
> For some hardware, GL_RGBA is the safest option for textures to bind to
> an FBO for depth 8 as GL_ALPHA might be unsupported.
>
> This allows using glamor-xv on hardware that don't support GL_ALPHA
> textures attaching to an FBO, such as nouveau on nv30.
>
> Newer hardw
Martin Peres writes:
> On 11/04/17 04:47, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this point, the
>>> kernel should mark thi
Martin Peres writes:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before setting the offending connector's
Adam Jackson writes:
> Dead code since:
>
> commit 8aacf47e1778d8b72811b025a82452b933d3c1f2
> Author: Adam Jackson
> Date: Fri Oct 4 12:58:19 2013 -0400
>
> glx: Remove DRI1 AIGLX (v2)
>
> Signed-off-by: Adam Jackson
Reviewed-by: Eric Anholt
Adam Jackson writes:
> Otherwise xcb will treat our attempt to send xv requests as a connection
> error (quite reasonably: we're asking it to emit a request for which
> there is no defined major opcode), and we'll die quietly the first time
> we hit KdBlockhandler.
Re
Jon Turney writes:
> Signed-off-by: Jon Turney
Tested and pushed. Thanks!
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/list
Daniel Vetter writes:
> On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
>> Manasi Navare writes:
>>
>> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
>> >> Manasi Navare writes:
>> >>
>> >> &
Manasi Navare writes:
> On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
>> Manasi Navare writes:
>>
>> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
>> >> Martin Peres writes:
>> >>
>> >> > On 26/01
Manasi Navare writes:
> On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
>> Martin Peres writes:
>>
>> > On 26/01/17 14:37, Martin Peres wrote:
>> >> Despite all the careful planing of the kernel, a link may become
>> >> insufficient
Martin Peres writes:
> On 26/01/17 14:37, Martin Peres wrote:
>> Despite all the careful planing of the kernel, a link may become
>> insufficient to handle the currently-set mode. At this point, the
>> kernel should mark this particular configuration as being broken
>> and potentially prune the m
Keith Packard writes:
> [ Unknown signature status ]
> Eric Anholt writes:
>
>> Unaligned accesses trap on some platforms, and I don't think we're
>> guaranteed that the caller has the pointer aligned (at least, the
>> previous code seemed pretty clearly
Adam Jackson writes:
> No driver is using these, as far as I know.
>
> v2: Tripwire the entity hook arguments to xf86Config*Entity, fix
> documentation (Eric Anholt)
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
__
-time autodetection, non-recursive make, and no
libtool, so it seems like an interesting test-case to start with for
meson conversion.
v2: Add missing check for err.h
v3: Add a linebreak after printing the version (by Peter),
fix manpage variable substitution (anholt).
Signed-off-by: Eric A
The previous code was contorting itself to do the substitution in the
same source format as the xorg automake macros. Now that automake is
gone, we can simplify it.
Signed-off-by: Eric Anholt
---
man/rendercheck.man | 2 +-
meson.build | 15 ---
2 files changed, 5
Signed-off-by: Eric Anholt
---
README | 8
1 file changed, 8 insertions(+)
diff --git a/README b/README
index f5af0b0c64eb..2f8ec1ab0e46 100644
--- a/README
+++ b/README
@@ -10,3 +10,11 @@ Tests currently include:
- Linear gradients
- Repeating sources/masks at POT and non-POT sizes
Signed-off-by: Eric Anholt
---
.gitignore | 79 -
Makefile.am | 43 ---
autogen.sh | 17 -
configure.ac| 29 -
main.c | 6 -
man/Makefile.am | 38
Peter Hutterer writes:
> On Fri, Mar 24, 2017 at 01:17:49PM -0700, Eric Anholt wrote:
>> ---
>> man/rendercheck.man | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/man/rendercheck.man b/man/rendercheck.man
>> index b7be417
Peter noted a weirdness in my new bswap code, which could use some
tests to justify it.
Signed-off-by: Eric Anholt
---
test/misc.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/test/misc.c b/test/misc.c
index ae46bab9..c10a2b935bc4 100644
Peter Hutterer writes:
> On Mon, Mar 27, 2017 at 03:11:03PM -0700, Eric Anholt wrote:
>> The clever pointer tricks were actually not working, and we were doing
>> the byte-by-byte moves in general. By just doing the memcpy and
>> obvious byte swap code, we end up genera
Adam Jackson writes:
> No driver is using these, as far as I know.
If we're going to leave the args in place for xf86ConfigPciEntity, could
we assert that init/enter/leave are NULL, to catch if a driver *did*
exist that used them?
The docs for xf86ConfigPciEntity() should probably also note tha
Aaron Plattner writes:
> Some drivers don't support SHM pixmaps, but rendercheck doesn't care and tries
> to use them anyway. This causes the test to abort:
Reviewed and pushed. Thanks!
signature.asc
Description: PGP signature
___
xorg-devel@lists.x
The clever pointer tricks were actually not working, and we were doing
the byte-by-byte moves in general. By just doing the memcpy and
obvious byte swap code, we end up generating actual byte swap
instructions, thanks to optimizing compilers.
text data bss dec hex filena
This dumps a ton of configure-time checks for system endian macros.
Given that we're marking the mixed-endian fixup code as cold, getting
at the system macros is a waste of code.
Signed-off-by: Eric Anholt
---
configure.ac| 60 -
As far back as the initial import, it seems to have been exposed, and
there's no explanation why the test happened in the initial xserver
import.
Signed-off-by: Eric Anholt
---
configure.ac | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
Adam Jackson writes:
> On Mon, 2017-03-27 at 12:35 -0400, Adam Jackson wrote:
>> On Fri, 2017-03-24 at 13:44 -0700, Eric Anholt wrote:
>>
>> > This is the only functional change I spotted: SaveScreen is now
>> > going to
>> > return FALSE instea
ot; logic into the
> DPMS extension's (new) reset hook. This would be a behavior change for
> the non-xfree86 servers, if any of them had non-stub DPMS support.
>
> Signed-off-by: Adam Jackson
I took another look today, and this series is:
Reviewed-by: Eric Anholt
Mark Kettenis writes:
>> From: Eric Anholt
>> Date: Fri, 24 Mar 2017 13:17:45 -0700
>>
>> Having bitten off a bit more than I can chew in 3 days with the X
>> Server (hw/xfree86/sdksyms.c is the worst), I decided to take a quick
>> pass at converting a proj
Meson allows the configure step to be run faster (.3 seconds compared to
autogen.sh's 3.9 seconds on my system) and a full rebuild (touch
rendercheck.h; make) to run faster (.05s instead of .07s).
Rendercheck is pretty much the best case scenario for autotools, with
limited configure-time autodete
is now going to
return FALSE instead of TRUE. Given that we haven't actually blanked
the screen, this seems like an appropriate return value.
With a note in the commit message about this behavior change (or, even
better, if DPMS was pulled into a separate commit), the series will be:
Reviewe
Adam Jackson writes:
> On Fri, 2017-03-24 at 10:34 -0700, Eric Anholt wrote:
>> > Adam Jackson writes:
>>
>> > Rather than setting up a per-screen private, just conditionally
>> > initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
&g
---
man/rendercheck.man | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/rendercheck.man b/man/rendercheck.man
index b7be417d5c37..8b7dccab7725 100644
--- a/man/rendercheck.man
+++ b/man/rendercheck.man
@@ -1,5 +1,5 @@
.ds q \N'34'
-.TH rendercheck 1 __xorgversion__
+.TH re
---
README | 8
1 file changed, 8 insertions(+)
diff --git a/README b/README
index f5af0b0c64eb..2f8ec1ab0e46 100644
--- a/README
+++ b/README
@@ -10,3 +10,11 @@ Tests currently include:
- Linear gradients
- Repeating sources/masks at POT and non-POT sizes
- Some regression tests for
---
rendercheck.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rendercheck.h b/rendercheck.h
index 1c392e8d69fd..7dc9dc95c38d 100644
--- a/rendercheck.h
+++ b/rendercheck.h
@@ -37,7 +37,7 @@ static inline void errx(int eval, const char *fmt, ...) {
va_start(args, fmt);
ranch over to meson. I ended up not
finishing the travis-ci work because the build time of running 17
autogen.sh's on travis was so long that I got bored.
Eric Anholt (5):
Fix a printf format warning.
Add a meson build system.
Remove the autotools build system.
Convert the manp
Meson allows the configure step to be run faster (.3 seconds compared to
autogen.sh's 3.9 seconds on my system) and a full rebuild (touch
rendercheck.h; make) to run faster (.05s instead of .07s).
Rendercheck is pretty much the best case scenario for autotools, with
limited configure-time autodete
---
.gitignore | 79 -
Makefile.am | 43 ---
autogen.sh | 17 -
configure.ac| 29 -
main.c | 6 -
man/Makefile.am | 38 ---
6
Adam Jackson writes:
> Rather than setting up a per-screen private, just conditionally
> initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
> that to determine whether DPMS is supported.
>
> We also move the "turn the screen back on at CloseScreen" logic into the
> DPMS exte
It had nothing left in it that was used but wasn't in dix-config.h.
---
configure.ac | 7 +--
hw/kdrive/ephyr/Makefile.am | 1 +
hw/kdrive/ephyr/ephyr.c | 4 ++--
hw/kdrive/ephyr/ephyr_draw.c | 4 ++--
hw/kdrive/ephyr/ephyr_glamor_xv.c | 4 ++--
h
n a tiny fraction of the time it takes to ./configure.
In the process, I've run into some silly stuff in our tree that could
be cleaned up independently of whether we go with meson.
Eric Anholt (7):
kdrive: Unifdef KDRIVE_EVDEV.
kdrive: Remove vestiges of TSLIB support.
kdrive: Drop k
---
glamor/glamor_priv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 27f95521dd3d..7b92f35705f4 100644
--- a/glamor/glamor_priv.h
+++ b/glamor/glamor_priv.h
@@ -910,7 +910,7 @@ int glamor_xv_put_image(glamor_port_private *po
ajax deleted the evdev driver in the removal of fbdev and the linux
backend.
Signed-off-by: Eric Anholt
---
hw/kdrive/ephyr/ephyrinit.c | 10 --
hw/kdrive/src/kinput.c | 25 -
include/kdrive-config.h.in | 3 ---
3 files changed, 38 deletions(-)
diff --git
The actual code was gone in 27819950e4158326e0f83a30f2e8968b932625ef,
but some checks remained.
---
configure.ac | 5 ++---
include/dix-config.h.in| 6 --
include/kdrive-config.h.in | 3 ---
include/xorg-server.h.in | 3 ---
4 files changed, 2 insertions(+), 15 deletions(-)
The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-config.h.
---
hw/xfree86/modes/xf86Crtc.c | 3 ---
hw/xfree86/modes/xf86Cursors.c | 3 ---
hw/xfree86/modes/xf86DiDGA.c | 3 ---
hw/xfree86/modes/xf86EdidModes.c | 3 ---
hw/xf
- * SOFTWARE.
- *
- * Authors:
- *Eric Anholt
- *
- */
-
-#ifdef HAVE_DIX_CONFIG_H
-#include
-#endif
-
-#include "ephyr.h"
-#include "exa_priv.h"
-#include "fbpict.h"
-
-#define EPHYR_TRACE_DRAW 0
-
-#if EPHYR_TRACE_DRAW
-#define TRACE_DRAW() ErrorF("%s\n"
---
hw/xfree86/exa/examodule.c | 2 +-
hw/xwayland/xwayland-shm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/exa/examodule.c b/hw/xfree86/exa/examodule.c
index 76f780ab6d6f..0bbd93e34015 100644
--- a/hw/xfree86/exa/examodule.c
+++ b/hw/xfree86/exa/examodule.c
@@ typedef struct {
> #define X_GLXDestroyWindow 32
> #define X_GLXSetClientInfoARB33
> #define X_GLXCreateContextAttribsARB 34
> -#define X_GLXSetConfigInfo2ARB 35
> +#define X_GLXSetClientInfo2ARB 35
Mesa and xserver don't s
Adam Jackson writes:
> None of this is actually wired up to anything, so we can also remove the
> devPrivates from the DamageRec. The DamageExtRec is what would need
> devPrivates for selinux labeling, in principle.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP
Adam Jackson writes:
> Same trick as in fb: just do a normal GetImage and deal with the
> planemask on the CPU if you have to. Since the software fallback hit for
> glamor is pretty brutal, this is a much more impressive win for glamor
> than it was for fb:
>
> 11100.0 87700.0 (7.901) (copy 0x
in, but then the MergeRop
isn't just a single & operation.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Kenneth Graunke writes:
> Copied from Mesa with no modifications. Gives us Geminilake PCI IDs.
>
> Signed-off-by: Kenneth Graunke
Acked-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org de
s cmdline or a
> xorg.conf snippet.
I think this is a sensible default. It also helped with getting X up on
my VC4 + CLCD platform.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Olivier Fourdan writes:
> Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
> is raised, in which case the texture returned is zero.
>
> But the texture value is not checked in glamor_create_fbo() and glamor
> will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0
Eric Anholt writes:
> We were binding the screen pixmap as the dash and sampling its alpha,
> which is usually just 1.0 (no dashing at all).
>
> Please cherry-pick this to active stable branches.
Pushed. Thanks everyone!
signature.asc
Description: P
Keith Packard writes:
> [ Unknown signature status ]
> Eric Anholt writes:
>
>> We were binding the screen pixmap as the dash and sampling its alpha,
>> which is usually just 1.0 (no dashing at all).
>>
>> Please cherry-pick this to active stable branches.
We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt
---
glamor/glamor_dash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor
g on this working
without an X connection being possible.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman
er drivers support 32bpp. Configurations that
> explicitly request 24bpp in order to fit in VRAM will be broken now
> though.
I am so happy to see all this ugly code gone. Series is:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
__
Keith Packard writes:
> [ Unknown signature status ]
> Adam Jackson writes:
>
>> Is there some reason you believe GL's rasterisation rules for lines
>> match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
>> a bit looser than fb to me.
>
> I think they're 'good enough'; there
Michel Dänzer writes:
> From: Michel Dänzer
>
> Or if the cache watermark is reached, whichever comes earlier.
>
> This slightly simplifies the FBO cache management, and prevents it from
> potentially holding entries for a long time, while preserving the main
> benefit of the cache for bursts of
Adam Jackson writes:
> This touches everything that ends up in the Xorg binary; the big missing
> part is GLX since that's all generated code. Cuts about 14k from the
> binary on amd64.
Reviewed-by: Eric Anholt
signature.asc
Description:
one of this varies within a screen, we can move the clip
> management funcs up to the ScreenRec and eliminate the empty wrappers.
I tried to come up with a reason I would want a layer to be able to
change the funcs per-gc at runtime, and failed. Yay for killing
boilerplate.
Reviewed-by: Eric An
be pretty OK with that plan, but for this patch, at least:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Adam Jackson writes:
> On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote:
>> Max Staudt writes:
>>
>> > Okay, so do you think we can take the patch for the GXcopy case,
>> > and fall back to mi otherwise?
>>
>> We shouldn't mask driver bugs like this; is there some reason you
>> believe w
Martin Peres writes:
> On 06/02/17 17:50, Martin Peres wrote:
>> On 03/02/17 10:04, Daniel Vetter wrote:
>>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
>>>> On 01/02/17 22:05, Manasi Navare wrote:
>>>>> On Wed, Feb 01, 2017 at 11:
Daniel Vetter writes:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
>> Jani Nikula writes:
>>
>> > On Tue, 31 Jan 2017, Eric Anholt wrote:
>> >> Martin Peres writes:
>> >>
>> >>> Despite all the careful planing
Jani Nikula writes:
> On Tue, 31 Jan 2017, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this point, the
>>> kernel should m
Martin Peres writes:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before setting the offending connector's
Olivier Fourdan writes:
> When selecting "CA_TWO_PASS" in glamor_composite_clipped_region() when
> the hardware does not support "GL_ARB_blend_func_extended", we call
> glamor_composite_choose_shader() twice in a row, which in turn calls
> glamor_pixmap_ensure_fbo().
>
> On memory pixmaps, the fi
any rgb565 visual ahead of the argb visual.
>
> Signed-off-by: Adam Jackson
Nice fix. The series is:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x
Adam Jackson writes:
> From: Emil Velikov
>
> Now that used can set the path only via LoaderSetPath(), we can simplify
"users"?
Other than that, 4-14 are:
Reviewed-by: Eric Anholt
There is so much "wow, remember when that was a thing?" in this series.
Time to g
Adam Jackson writes:
> From: Emil Velikov
>
> Similar to its little brothre - LoadSubModule. Currently all call sites
> provide NULL anyway ;-)
"brother". Other than that,
Reviewed-by: Eric Anholt
signature.asc
Desc
* LoadSubModule's path"?
Potential followup: ddxDesign.xml's LoaderSetPath() docs refer to these
functions taking a path, when they don't any more.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@list
Olivier Fourdan writes:
> Hi all,
>
> I am trying to investigate an issue with Xwayland that affects pixmap
> rendering only some hardware with nouveau (basically, older hardware).
>
> Initally, I started looking into this because of reported black icons in
> gtk2 (X11/Xwayland) apps in GNOME and
Alan Coopersmith writes:
> On 11/22/16 04:58 PM, Eric Anholt wrote:
>> Adam Jackson writes:
>>
>>> Signed-off-by: Adam Jackson
>>> ---
>>> configure.ac | 5 +
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>>
Adam Jackson writes:
> Signed-off-by: Adam Jackson
> ---
> configure.ac | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 6fd853b..93c81a6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2138,10 +2138,7 @@ AM_CONDITIONAL([XOR
Mark yao writes:
> On 2016年11月15日 02:32, Eric Anholt wrote:
>> Mark yao writes:
>>
>>> Hi Eric
>>>
>>> We found some display problem when rotate the screen.
>>>
>>> You can see the abnormal display picture on attachment.
>>&
Mark yao writes:
> Hi Eric
>
> We found some display problem when rotate the screen.
>
> You can see the abnormal display picture on attachment.
>
> Bug reproduce step:
> 1, run lubuntu session.
> 2, rotate screen: xrandr --output eDP-1 --rotate right
> 3, run lxterminal, enter some message, move
nc handlers in
> case of failure when checking for the minimum requirements, so that if
> any of the requirement is not met we don't leave the CloseScreen() and
> DestroyPixmap() from glamor handlers in place.
>
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=139
Adam Jackson writes:
> Regeneration is fast enough these days, we can skip this. This
> eliminates about 40 minutes of wall time from a full xts run.
If not sleeping is a problem, we should figure out a way to make
regeneration not racy. Sleeps aren't OK.
Reviewed-by:
Echelon9 writes:
> From: Rhys Kidd
>
> Box.c:245:7: error: non-void function 'DoLayout' should return a value
> [-Wreturn-type]
> return;
> ^
> Box.c:285:6: error: non-void function 'DoLayout' should return a value
> [-Wreturn-type]
>
Martin Peres writes:
> On 21/10/16 19:18, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> This allows a runner such as EzBench to track each test individually
>>> and not limit the resolution to groups.
>>>
>>> This feature can be triggered
Adam Jackson writes:
> On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote:
>> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov
>> wrote:
>> > > > From: Emil Velikov
>> >
>> > As pointed out in the ABI tracker[1], epoxy has gone through a few
>> > non-backwards compatible ABI changes, yet prese
Martin Peres writes:
> This allows a runner such as EzBench to track each test individually
> and not limit the resolution to groups.
>
> This feature can be triggered by using the -r parameter.
I don't really see the point of this -- you need an external runner to
be choosing a specific test su
Adam Jackson writes:
> This is a step towards making libglamor_egl and Xwayland not link
> against libGL (which brings in client-side libraries, which is just
> icky).
Is it actually necessary? Given that the epoxy GLX symbols always
exist, and we're linking against epoxy, it seems like we coul
-noreset \
> -screen scrn 1280x1024x24"
> export PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/xvfb
Thanks. I tried to be careful about it when writing these scripts, but
I don't do OOT myself. Once I get that Travis script done, that will do
OOT builds, at
Keith Packard writes:
> If we're never painting anything in the window, we probably don't need
> to map it.
>
> Signed-off-by: Keith Packard
Drop the extern ephyr_glamor_gles2 and it's:
Reviewed-by: Eric Anholt
signature.asc
d works around a quirk in epoxy.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Adam Jackson writes:
> On Fri, 2016-09-30 at 22:43 -0700, Keith Packard wrote:
>
>> 1 2 Operation
>> - -
>> 10900.099900.0 ( 9.165) PutImage XY 10x10 square
>> 1740.0
Keith Packard writes:
> Use the glamor_put_image_xy_gl for small images as that is quite a bit
> faster.
I'd like to see some performance data in the commit messages. With
that, this will all be r-b. Thanks!
I'm hoping that once we do VAOs that will greatly improve our
performance for the 10x
Mark Yao writes:
> since commit (9e9fcf5 glamor: Add a helper function for the common
> GL_QUADS fallback pattern.), the glDrawArrays count change to nbox,
> That is wrong, I think it maybe cause by fat finger.
>
> Signed-off-by: Mark Yao
Thanks! This fixes xlogo on a GL 2.1 implementation.
I
Signed-off-by: Eric Anholt
---
glamor/glamor_utils.h | 171 --
1 file changed, 171 deletions(-)
diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h
index 561761167fd8..e6398692e3d6 100644
--- a/glamor/glamor_utils.h
+++ b/glamor
201 - 300 of 1134 matches
Mail list logo
