Dnia poniedziałek, 5 listopada 2012, Thomas Lübking napisał:
[...]
Observation:
you're running 1600x1200@85Hz while basic Single Link DVI has it's
maximum at 1600x1200@60Hz
To run higher resolutions or frequency, the entire chain has to support
reduced blanking capabilities and there's
On Tue, Nov 06, 2012 at 13:58:31 +0100, tino.keitel+x...@tikei.de wrote:
On Tue, Nov 06, 2012 at 13:45:26 +0100, Łukasz Maśko wrote:
[...]
Your report is very similar to mine. I'm also using 1600x1200 resolution.
My
machine has DVI, but monitor does not. So I'm also using VGA
My laptop has an Intel 945GM graphics and it is working more-less correctly
(I'm using kernel 3.5.7, Intel driver 2.20.12 and xserver 1.13.0). But some
time ago I've noticed some strange artefacts around menus or hint boxes (the
ones that appear after you stop a mouse pointer on a button, for
On Donnerstag, 8. November 2012 12:02:52 CEST, Łukasz Maśko wrote:
But some time ago I've noticed some
strange artefacts around menus or hint boxes (the ones that
appear after you stop a mouse pointer on a button, for
instance). I've made a screenshot, so you can observe it
yourself:
On Wed, Oct 17, 2012 at 12:06:47PM +0200, Thierry Reding wrote:
For non-PCI video devices, such as those found on many ARM embedded
systems, the X server currently requires the BusID option to specify the
full path to the DRM device's sysfs node in order to properly match it
against the probed
This silences a warning from libtoolize when running the autogen.sh
script.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
Makefile.am | 2 ++
autogen.sh | 1 +
configure.ac | 1 +
3 files changed, 4 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index
Recent versions of the X server no longer provide this function, which
has been obsolete for over 2 years now.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
src/driver.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/driver.c b/src/driver.c
index 38a1c09..4866585
Various DIX patches
Patches #2, #4 and #7 touch Xquartz to adjust for these changes, and I have
tried to ensure that they do the right thing, but I am not able to test that
Xquartz builds with those changes.
Jon TURNEY (7):
os: Remove any old logfile before trying to write to it
Allow DDX
If we are not backing up logfiles, remove the old logfile before trying to write
a new logfile, as otherwise the operation may fail if the previous logfile was
created by a different user.
This change is useful when:
- The DDX doesn't use the logfile backup mechanism (i.e. not Xorg)
- The DDX is
XQuartz already conditionally renames main() as dix_main() so it can provide
it's own main(). This isn't ideal as it prevents libdix built this way from
being useful with any other DDX.
So instead, always name that function dix_main(), and provide a stub main()
which just calls it where needed.
https://bugs.freedesktop.org/show_bug.cgi?id=30102
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
Reviewed-by: Colin Harrison colin.harri...@virgin.net
---
glx/rensize.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/glx/rensize.c b/glx/rensize.c
index
Move pseudoramiX code to a separate top-level directory. Link Xwin and Xquartz
with libPseudoramiX
I'm not sure moving this to a top-level directory is appropriate, but I'm not
sure where else it fits.
Future work: pseudoramiX can probably be consolidated with the rrxinerama code
(which I think
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
Xext/Makefile.am |4 +++-
hw/vfb/Makefile.am |4 ++--
hw/xnest/Makefile.am |4 ++--
hw/xwin/Makefile.am |4 ++--
test/Makefile.am |2 +-
5 files changed, 10 insertions(+), 8 deletions(-)
diff --git
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
Xi/Makefile.am |5 +++--
hw/vfb/Makefile.am |4 ++--
hw/xnest/Makefile.am |4 ++--
hw/xwin/Makefile.am |4 ++--
test/Makefile.am |4 ++--
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git
Revisit b3415187e92960cbff784108b5a3a8d130dc34c5, which shoves some rootless
specific code directly into miPaintWindow.
Unfortunately as written, this means that dix mi/libmi (when built with ROOTLESS
defined) must be linked into a ddx which links with miext/rootless/librootless,
which makes it
GCC complains about these variables being set but not used, so they can
just as well be removed.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
hw/xfree86/common/xf86Helper.c | 4 +---
hw/xfree86/modes/xf86RandR12.c | 14 --
2 files changed, 1 insertion(+), 17
The output's physical dimensions may be set by the driver, which is the
case at least for xf86-video-modesetting. It makes no sense to overwrite
it with 0 if EDID is unavailable because it will cause the only source
of this information to be lost.
Signed-off-by: Thierry Reding
The X server start up with the assumption that the display has 96 DPI
unless configured otherwise. However under the proper circumstances, it
can compute the correct value from the information provided by output
resources.
This commit adds this computation directly in xf86RandR12ScreenSetSize()
If an output provides its physical dimensions, they should be used in
preference to computing them on the assumption that the display has a
default DPI setting.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
hw/xfree86/modes/xf86RandR12.c | 12 +---
1 file changed, 9
Am 08.11.2012 14:41, schrieb Jon TURNEY:
If we are not backing up logfiles, remove the old logfile before trying to
write
a new logfile, as otherwise the operation may fail if the previous logfile was
created by a different user.
what are the permissions of that file ?
normally you can
On 08/11/12 18:21, walter harms wrote:
Am 08.11.2012 14:41, schrieb Jon TURNEY:
If we are not backing up logfiles, remove the old logfile before trying to
write
a new logfile, as otherwise the operation may fail if the previous logfile
was
created by a different user.
what are the
Hey there, everyone.
I've recently had to test some code which relies on GLX using Xvfb on
xorg-server 1.13.0, but it looks like it is not loaded anymore after
commit 5f5bbbe543f65c48ecbb5cce80116a86ca3fbe86.
It turns out that this commit removed a duplicate code path in
miinitext.c which was
These all seem fine to me. For the series,
Reviewed-by: Aaron Plattner aplatt...@nvidia.com
-- Aaron
On 11/08/2012 05:50 AM, Thierry Reding wrote:
GCC complains about these variables being set but not used, so they can
just as well be removed.
Signed-off-by: Thierry Reding
On Mon, Oct 29, 2012 at 6:38 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 59fd496..e3afde3 100644
---
On Thu, Nov 1, 2012 at 10:17 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
https://bugs.freedesktop.org/show_bug.cgi?id=56557
Pointer emulation on the root window does not work correctly. We currently
only deliver to window owners, but no client owns the root window. The real
bug here
On Mon, Nov 5, 2012 at 5:28 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
Virtually everyone trying the tests the first time will run into this issue
since we cannot check if the ABI for dummy and whatever else is needed
actually matches the server (well, we have a test for that, but
On Tue, Nov 6, 2012 at 2:52 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
The man page itself already contained the description, but it was missing
from NAME so the shadow man pages were not generated.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
man/Makefile.am | 6
On Tue, Nov 6, 2012 at 7:57 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
Xlib's default error handler prints the error and calls exit(1). Tests that
accidentally trigger an error thus quit without cleaning up properly.
Install a default error handler that prints the basic info and
On Tue, Nov 6, 2012 at 7:57 PM, Peter Hutterer peter.hutte...@who-t.netwrote:
This header is for self-testing, specifically EXPECT_FATAL_FAILURE
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
gtest/include/Makefile.am | 2 +-
gtest/include/gtest/gtest-spi.h | 232
On Wed, Oct 17, 2012 at 8:06 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
For non-PCI video devices, such as those found on many ARM embedded
systems, the X server currently requires the BusID option to specify the
full path to the DRM device's sysfs node in order to properly
On 30 October 2012 12:38, Peter Hutterer peter.hutte...@who-t.net wrote:
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_MACRO_DIR([m4])
# Initialize Automake
-AM_INIT_AUTOMAKE([foreign dist-bzip2])
+AM_INIT_AUTOMAKE([foreign dist-bzip2
On Fri, Nov 09, 2012 at 01:44:16PM +1100, Daniel Stone wrote:
On 30 October 2012 12:38, Peter Hutterer peter.hutte...@who-t.net wrote:
--- a/configure.ac
+++ b/configure.ac
@@ -8,7 +8,7 @@ AC_CONFIG_SRCDIR([Makefile.am])
AC_CONFIG_MACRO_DIR([m4])
# Initialize Automake
On Thu, Nov 08, 2012 at 05:46:12PM -0800, Chase Douglas wrote:
On Tue, Nov 6, 2012 at 7:57 PM, Peter Hutterer
peter.hutte...@who-t.netwrote:
Xlib's default error handler prints the error and calls exit(1). Tests that
accidentally trigger an error thus quit without cleaning up properly.
https://bugs.freedesktop.org/show_bug.cgi?id=56621
--- Comment #11 from maveri...@gmail.com ---
Same corruption with same paul's gnome 3.4 3.6 upgrade on archlinux x86_64,
with a Radeon HD3650
[ 119.497525] [TTM] Failed to find memory space for buffer 0x88010949d048
eviction
[
https://bugs.freedesktop.org/show_bug.cgi?id=54273
--- Comment #27 from Alexandre Bique bique.alexan...@gmail.com ---
This is the radeon regs with linux 3.6.6 (from archlinux) and kms:
RADEON_DAC_CNTL
RADEON_DAC_EXT_CNTL
RADEON_DAC_MACRO_CNTL
RADEON_DAC_CNTL2
https://bugs.freedesktop.org/show_bug.cgi?id=54273
--- Comment #28 from Alexandre Bique bique.alexan...@gmail.com ---
I just tried to boot with the catalyst-firepro driver, but as it doesn't
support xorg 1.13, I can't dump the registers with the official driver.
Can we check that the previous
https://bugs.freedesktop.org/show_bug.cgi?id=56621
--- Comment #12 from Alex Deucher ag...@yahoo.com ---
Can you try booting with radeon.gartsize=1024? Ideally with a 3.7 kernel.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=42854
pedram.na...@gmail.com changed:
What|Removed |Added
CC||pedram.na...@gmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=54273
--- Comment #29 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #28)
Can we check that the previous registers dump is correct to set
2560x1600@60Hz?
Those aren't the right registers, it looks like you are using radeontool rather
https://bugs.freedesktop.org/show_bug.cgi?id=56621
--- Comment #13 from Veli-Jussi Raitila v...@iki.fi ---
I tried the mainline kernel 3.7rc4 with radeon.gartsize=1024
No corruption, but the kernel error messages are still there.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=56621
--- Comment #14 from Veli-Jussi Raitila v...@iki.fi ---
Created attachment 69767
-- https://bugs.freedesktop.org/attachment.cgi?id=69767action=edit
Kernel error messages with 3.7rc4 and radeon.gartsize=1024
Here are the messages I get (without
https://bugs.freedesktop.org/show_bug.cgi?id=54273
--- Comment #30 from Alexandre Bique bique.alexan...@gmail.com ---
Created attachment 69768
-- https://bugs.freedesktop.org/attachment.cgi?id=69768action=edit
radeon.regs
Add radeon.regs
--
You are receiving this mail because:
You are the
42 matches
Mail list logo