Maintenance branch release, primarily for bdftopcf's benefit as it's
the only thing that really needs the Xfont1 API. (xfs uses it too, I
believe, but could be ported to Xfont2). If someone wanted to step up
and merge Xfont1 into bdtopcf directly, that'd be great.
Adam Jackson (1):
libXfont
On 31 August 2016 at 22:10, Hans de Goede wrote:
> Hi All,
>
> I've noticed a weird sw-cursor issue when a slave-output is active
> (I believe this is a sw-cursor issue because show_cursor never
> gets called when a slave-output is active at server start).
>
> I'm seeing
Emacs was indenting badly in the previous change without it.
---
.editorconfig | 12
1 file changed, 12 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index ..5fa2d6311abd
--- /dev/null
+++ b/.editorconfig
---
autogen.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/autogen.sh b/autogen.sh
index fc34bd55c443..ee30ef4aa858 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -9,6 +9,9 @@ cd $srcdir
autoreconf -v --install || exit 1
cd $ORIGDIR || exit $?
+git config --local --get
One less environment variable the user needs to set to prevent
spurious failures.
---
src/tet3/apilib/Makefile.am | 3 ++-
src/tet3/apilib/dconfig.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/tet3/apilib/Makefile.am b/src/tet3/apilib/Makefile.am
index
On 1 September 2016 at 11:28, Michel Dänzer wrote:
> On 01/09/16 10:24 AM, Michel Dänzer wrote:
>> On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie said:
On 31 August 2016 at 22:10, Hans de
By default the tests will be skipped. However, if you set XTEST_DIR
to the repo of a built X Test Suite and PIGLIT_DIR to a piglit repo
(no build necessary), make check will run piglit's xts-render tests
against Xvfb.
We could run more of XTS5, but I haven't spent the time identifying
what
On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie said:
> On 31 August 2016 at 22:10, Hans de Goede wrote:
> > Hi All,
> >
> > I've noticed a weird sw-cursor issue when a slave-output is active
> > (I believe this is a sw-cursor issue because show_cursor
Signed-off-by: Peter Hutterer
---
Well, that'll teach me to send untested patches. Sorry.
Changes to v1:
- add libinput special handling to clone()
- confirmed it actually worked :)
build.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie said:
>> On 31 August 2016 at 22:10, Hans de Goede wrote:
>>> Hi All,
>>>
>>> I've noticed a weird sw-cursor issue when a slave-output is active
Package: xserver-xorg-video-ati
Version: 1:7.6 & 1:7.7
Good day Debian world,
I'm curious if you've observed a performance regression in Xorg versions
above 1:7.5 (i.e. any version that can use DRI3) for integrated Radeon
chips using the r300 driver.
At least in Ubuntu, when using any version
On 01/09/16 10:24 AM, Michel Dänzer wrote:
> On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie said:
>>> On 31 August 2016 at 22:10, Hans de Goede wrote:
Hi All,
I've noticed a
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
include/scrnintstr.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index 5330714..52e8382 100644
---
Any update on this?
On 20.06.2016 20:27, Hans de Goede wrote:
> Hi,
>
> On 20-06-16 18:32, Nikhil Mahale wrote:
>> Sorry for late reply, Hans. See inline -
>>
>> On 06/13/2016 10:36 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 20-05-16 07:00, Nikhil Mahale wrote:
For gpu screen, CrtcSet
On 31/08/16 05:56 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> include/scrnintstr.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/scrnintstr.h
When Xorg gets started directly from a wayland-gdm the crtc still has the
wayland hw cursor set. Combine this with Xorg immediately falling back to
a sw cursor because a slave-output has a monitor attached at startup; and
we end up with the wayland hardware cursor overlay fixed in its last
Hi All,
I've noticed a weird sw-cursor issue when a slave-output is active
(I believe this is a sw-cursor issue because show_cursor never
gets called when a slave-output is active at server start).
I'm seeing this with both 1.18 and master and with both the
intel and the modesetting drivers
On Wed, Aug 31, 2016 at 01:55:14PM +0200, Hans de Goede wrote:
> When Xorg gets started directly from a wayland-gdm the crtc still has the
> wayland hw cursor set. Combine this with Xorg immediately falling back to
> a sw cursor because a slave-output has a monitor attached at startup; and
> we
On Wed, Aug 31, 2016 at 10:16:34AM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> build.sh | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/build.sh b/build.sh
> index 369afc8..3006ebc 100755
> --- a/build.sh
> +++ b/build.sh
> @@
When Xorg gets started directly from a wayland-gdm the crtc still has the
wayland hw cursor set. Combine this with Xorg immediately falling back to
a sw cursor because a slave-output has a monitor attached at startup; and
we end up with the wayland hardware cursor overlay fixed in its last
The modesetting driver may be driving 2 screens (slave and master
gpu), which may have different behavior wrt hardware cursor support.
So stop using static variables and instead store the hw-cursor support
related data in a per screen struct. While at it actually make it per
crtc data as in
On Wed, Aug 31, 2016 at 4:56 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> include/scrnintstr.h | 19 +++
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=97228
--- Comment #12 from Dennis Mayr ---
I was finally trying to bisect, but this machine has run out of drive space
while compiling the drivers (old machine, tight budget), and there's not enough
time off-production to keep
Hans de Goede writes:
> The modesetting driver may be driving 2 screens (slave and master
> gpu), which may have different behavior wrt hardware cursor support.
>
> So stop using static variables and instead store the hw-cursor support
> related data in a per screen struct.
>
> OTOH this may indeed be a server bug, but your fix is not the right
> one, I wonder why we are doing a RRSetScreenSize for slave GPU-s at
> all. Since we already check that the Screen is big enough in
> ProcRRSetCrtcConfig?
We are looking for answer of this question, may be Dave or Ajax
25 matches
Mail list logo