Mouse buttons/scroll directions swapped with recent Xorg
Hello, Recently (beginning of February), I performed the following upgrades: xf86-input-evdev (2.6.0-4 - 2.6.99.901-1) xf86-input-synaptics (1.5.0-1 - 1.5.99-0.1) xorg-server (1.11.4-1 - 1.11.99.903-1) xorg-xinput (1.5.3-2 - 1.5.99.1-1) (Some of these packages have since been updated to their latest releases or newer snapshots, but the problems I describe below remain the same.) Since then, I have two problems: 1) On my ALPS touchpad, the circular scroll direction has been reversed: Scrolling left is now button 5, scrolling right is button 4. (The right edge of the touchpad still scrolls correctly, up is button 4, down is button 5.) 2) On my Logitech M555b mouse, buttons 6 and 7 have been swapped. I can't figure out where these problems occur. They could either be two separate problems in evdev and synaptics, or a single problem in xinput. I would appreciate any help to get this problem fixed. Regards and thanks Thomas signature.asc Description: OpenPGP digital signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
libXft 2.3.0 not so good
Distro makers probably want to hold off on packaging the 2.3.0 upgrade until we get a 2.3.1 release out to fix: https://bugs.freedesktop.org/show_bug.cgi?id=47178 https://bugs.freedesktop.org/show_bug.cgi?id=47196 (I guess no one noticed during the months the broken commits were sitting in git, but throw out a tarball, and suddenly people use it.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-video-vmware 12.0.0
- Original Message - On Thursday 08 of March 2012, Jakob Bornecrantz wrote: Full release of the new vmwgfx enabled driver bringing 3D to Linux guest on VMware products. Mostly this contains ABI fixes for X server 1.12. AC_CONFIG_FILES([ saa/Makefile vmwgfx/Makefile ]) but there are no such subdirectories in the tarball. Makefile.am looks wrong, these dirs are conditional, so make dist didn't package these. Arg, thanks for pointing this out, how do I best fix this? I'm not in good standing with automake. Cheers, Jakob. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
libXt 1.1.2 has regressions too
[Bug 47203] libxt 1.1.2 breaks xscreensaver https://bugs.freedesktop.org/show_bug.cgi?id=47203 [Bug 47216] upgrade to libxt 1.1.2 breaks windowless applications https://bugs.freedesktop.org/show_bug.cgi?id=47216 Package builders may want to watch out from those if they're considering an upgrade. Help from any developers with time knowledge to help track these down would be appreciated. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Desktop flash sometimes.
On 08/03/12 01:40 AM, qasdfgtyuiop wrote: Hi, I'm using Lenovo Ideapad Y460 laptop. My computer performs well at most time. But sometimes my screen flashs about every 1 seconds. Each flash will interrupt pull down menu and ibus IME input window. 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 425M] (rev ff) I also get a LVDS reset/flash. 01:00.0 VGA compatible controller: nVidia Corporation G71 [Quadro FX 1500M] (rev a1) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Special keys on Dell XPS L502X
Hi! I used showkey from console to get scancodes and keycodes for the three buttons. Also used dumpkeys to look up the keycodes. But these results are different from the ones I got using xev (see previous mail). Key I: -- scancode 0xe0 0x5b 0x2d 0xad 0xe0 0xdb keycode 125 press keycode 45 press keycode 45 release keycode 125 release keycode 45 is mapped to 'x' keycode 125 is mapped to 'Decr_Console' The biggest problem with this key is that it produces two keycodes although from reading I understood that each physical key should have just one keycode, but it could send multiple scancodes. So is this a bug? Also using xev I got different keycode for 'x'. I'm using Gnome3 as DE, but I expected keycodes to be the same between VT and Gnome3. Key II: --- scancode 0xe0 0x4c 0xe0 0xcc keycode 224 press keycode 224 release keycode 224 is mapped to 'nul' This one looks like it is not mapped, but in Gnome3 it decreased display brightness. Again DE does something different. Key III: scancode 0xe0 0x19 0xe0 0x99 keycode 163 press keycode 163 release keycode 163 is mapped to 'nul' Any pointers would be appreciated. Reinis ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Suggestion of patch for libXaw3d-1.6.1
No I didn't. However, the patch doesn't really use the specific features of Xaw3d, so it shouldn't be too hard to adapt it to make it work with plain Xaw. The advantage of Xaw3d is that it has already a more modern look and feel. (With plain Xaw, one would get a possibly strange combination of antialiased fonts with old style widgets...) In any case, it wouldn't be a big overhead except for the additional use of freetype. Best regards, Jean-Pierre Demailly It would be interesting to do so in order to keep Xaw and Xaw3d in sync. I agree, but although it wouldn't be a big task I currently have little available time ; I could possibly find the energy do it if you believe this has any chance to be integrated mainstream in both libXaw and libXaw3d - otherwise libXaw3dXft is possibly better left as a fork of libXaw3d ... btw i remember that tooltips where different in Xaw than on Xaw3d. Is this still true ? I haven't checked this yet, but it won't certainly be an issue for the additional stuff. JPD ___ 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
libXft 2.3.0 not so good
Distro makers probably want to hold off on packaging the 2.3.0 upgrade until we get a 2.3.1 release out to fix: https://bugs.freedesktop.org/show_bug.cgi?id=47178 https://bugs.freedesktop.org/show_bug.cgi?id=47196 (I guess no one noticed during the months the broken commits were sitting in git, but throw out a tarball, and suddenly people use it.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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
libXt 1.1.2 has regressions too
[Bug 47203] libxt 1.1.2 breaks xscreensaver https://bugs.freedesktop.org/show_bug.cgi?id=47203 [Bug 47216] upgrade to libxt 1.1.2 breaks windowless applications https://bugs.freedesktop.org/show_bug.cgi?id=47216 Package builders may want to watch out from those if they're considering an upgrade. Help from any developers with time knowledge to help track these down would be appreciated. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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
Re: [PATCH video-vmware] config: include saa and vmwgfx subdirs in the tarball
On Monday 12 of March 2012, Gaetan Nadon wrote: -SUBDIRS = @VMWGFX_DIRS@ src man vmwarectrl +# Order: vmwgfx before src +SUBDIRS = man saa vmwgfx src vmwarectrl make -j X will not obey this order. +if BUILD_VMWGFX +vmware_drv_la_LIBADD = $(top_builddir)/vmwgfx/libvmwgfx.la +vmware_drv_la_DEPENDENCIES = $(top_builddir)/vmwgfx/libvmwgfx.la +endif Isn't depentency here enough for make rules to find out the correct order? -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ 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
Re: [PATCH video-vmware] config: include saa and vmwgfx subdirs in the tarball
- Original Message - Use AM_CONDITIONAL. Automake knows what to distribute. It needs to be able to navigate down the subdirs to find what needs to be included in the tarball. To test reliably, create a tarball and expand it into a separate directory and build with xatracker. Distcheck will not detect missing code when such code is configured not to build. The content of a tarball *must* always be identical, regardless of the configuration options used or on which platform it was configured. Signed-off-by: Gaetan Nadon mems...@videotron.ca Thanks, I had just done a simpler patch, but less correct then yours, so I'll rather use this. Do we really need to do the conditional in all the Makefile.am's according to the link below that isn't needed and it will figure out DIST_SUBDIRS correctly? http://www.gnu.org/software/automake/manual/html_node/Subdirectories-with-AM_005fCONDITIONAL.html Cheers, Jakob. --- Makefile.am|4 +++- configure.ac | 18 ++ saa/Makefile.am|4 +++- src/Makefile.am|7 +-- vmwgfx/Makefile.am |6 +++--- 5 files changed, 20 insertions(+), 19 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1203715..64c019e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,9 @@ # IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -SUBDIRS = @VMWGFX_DIRS@ src man vmwarectrl +# Order: vmwgfx before src +SUBDIRS = man saa vmwgfx src vmwarectrl + MAINTAINERCLEANFILES = ChangeLog INSTALL .PHONY: ChangeLog INSTALL diff --git a/configure.ac b/configure.ac index cf1491f..af2737a 100644 --- a/configure.ac +++ b/configure.ac @@ -120,29 +120,23 @@ DRIVER_NAME=vmware AC_SUBST([DRIVER_NAME]) AC_MSG_CHECKING([whether to build Kernel Mode Setting and 3D]) -VMWGFX_DIRS= if test x$BUILD_VMWGFX = xyes; then AC_MSG_RESULT([yes]) AC_SYS_LARGEFILE - VMWGFX_DIRS=saa vmwgfx - VMWGFX_LIBADD='$(top_builddir)/vmwgfx/libvmwgfx.la' - AC_CONFIG_FILES([ - saa/Makefile - vmwgfx/Makefile - ]) -AC_DEFINE([BUILD_VMWGFX], 1, - [Building the vmwgfx driver path]) +AC_DEFINE([BUILD_VMWGFX], 1, [Building the vmwgfx driver path]) else AC_MSG_RESULT([no]) fi -AC_SUBST([VMWGFX_DIRS]) -AC_SUBST([VMWGFX_LIBADD]) +AM_CONDITIONAL(BUILD_VMWGFX, test x$BUILD_VMWGFX = xyes) + AC_CONFIG_FILES([ Makefile +man/Makefile +saa/Makefile +vmwgfx/Makefile src/Makefile vmwarectrl/Makefile -man/Makefile ]) AC_OUTPUT diff --git a/saa/Makefile.am b/saa/Makefile.am index 849ced9..48c9734 100644 --- a/saa/Makefile.am +++ b/saa/Makefile.am @@ -1,3 +1,5 @@ + +if BUILD_VMWGFX noinst_LTLIBRARIES = libsaa.la libsaa_la_CFLAGS = $(CWARNFLAGS) $(XORG_CFLAGS) @@ -10,4 +12,4 @@ libsaa_la_SOURCES = \ saa_render.c \ saa_accel.c \ saa.h - +endif diff --git a/src/Makefile.am b/src/Makefile.am index 1f54168..04c9e0d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -28,8 +28,11 @@ vmware_drv_la_LTLIBRARIES = vmware_drv.la vmware_drv_la_LDFLAGS = -module -avoid-version vmware_drv_la_CFLAGS = $(CWARNFLAGS) @XORG_CFLAGS@ vmware_drv_ladir = @moduledir@/drivers -vmware_drv_la_LIBADD = @VMWGFX_LIBADD@ -vmware_drv_la_DEPENDENCIES = @VMWGFX_LIBADD@ + +if BUILD_VMWGFX +vmware_drv_la_LIBADD = $(top_builddir)/vmwgfx/libvmwgfx.la +vmware_drv_la_DEPENDENCIES = $(top_builddir)/vmwgfx/libvmwgfx.la +endif vmware_drv_la_SOURCES = \ bits2pixels.c \ diff --git a/vmwgfx/Makefile.am b/vmwgfx/Makefile.am index 813f1a2..269d870 100644 --- a/vmwgfx/Makefile.am +++ b/vmwgfx/Makefile.am @@ -1,3 +1,5 @@ + +if BUILD_VMWGFX noinst_LTLIBRARIES = libvmwgfx.la libvmwgfx_la_CFLAGS = $(CWARNFLAGS) $(XORG_CFLAGS) @LIBDRM_CFLAGS@ @XATRACKER_CFLAGS@ -I$(top_srcdir)/src -I$(top_srcdir)/saa libvmwgfx_la_LIBADD = @LIBDRM_LIBS@ $(top_builddir)/saa/libsaa.la\ @@ -24,6 +26,4 @@ libvmwgfx_la_SOURCES = \ vmwgfx_xa_composite.c \ vmwgfx_xa_surface.c \ wsbm_util.h - - - +endif -- 1.7.5.4 ___ 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
Re: [PATCH macros] Add XORG_ENABLE_INTEGRATION_TESTS
On 03/11/2012 06:25 AM, Gaetan Nadon wrote: On 12-03-10 09:02 PM, Chase Douglas wrote: On 03/09/2012 05:33 PM, Gaetan Nadon wrote: On 12-03-09 05:49 PM, Chase Douglas wrote: Copied from XORG_ENABLE_UNIT_TESTS. Signed-off-by: Chase Douglaschase.doug...@canonical.com --- I pasted in a minimum version of 1.17.0, but I don't know if that's how we do things. yes, there is a bit of guess work here but it is the right number. This will be needed for xorg-gtest and integration testing in other projects. xorg-macros.m4.in | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 4966df3..9cd73c0 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1056,6 +1056,35 @@ AC_MSG_CHECKING([whether to build unit test cases]) AC_MSG_RESULT([$enable_unit_tests]) ]) # XORG_ENABLE_UNIT_TESTS +# XORG_ENABLE_INTEGRATION_TESTS (enable_unit_tests=auto) +# -- +# Minimum version: 1.17.0 +# +# This macro enables a builder to enable/disable integration testing +# It makes no assumption about the test cases' implementation +# Test cases may or may not use Automake Support for test suites +# +# Interface to module: +# ENABLE_INTEGRATION_TESTS: used in makefiles to conditionally build tests +# enable_integration_tests: used in configure.ac for additional configuration +# --enable-integration-tests: 'yes' user instructs the module to build tests +# 'no' user instructs the module not to build tests +# parm1: specify the default value, yes or no. +# +AC_DEFUN([XORG_ENABLE_INTEGRATION_TESTS],[ +AC_REQUIRE([XORG_MEMORY_CHECK_FLAGS]) +m4_define([_defopt], m4_default([$1], [auto])) +AC_ARG_ENABLE(integration-tests, AS_HELP_STRING([--enable-integration-tests], +[Enable building integration test cases (default: ]_defopt[)]), +[enable_integration_tests=$enableval], +[enable_integration_tests=]_defopt) +m4_undefine([_defopt]) +AM_CONDITIONAL([ENABLE_INTEGRATION_TESTS], +[test x$enable_integration_tests != xno]) +AC_MSG_CHECKING([whether to build unit test cases]) +AC_MSG_RESULT([$enable_integration_tests]) +]) # XORG_ENABLE_INTEGRATION_TESTS + # XORG_WITH_GLIB([MIN-VERSION], [DEFAULT]) # # Minimum version: 1.13.0 You must have considered using ENABLE_UNIT_TESTS but came to the conclusion that it would not be suitable. On the other hand it seems to do exactly the same thing. Can you share your conclusions? The motivation behind ENABLE_UNIT_TEST is to solve the problem where a few modules started adding unit testing, each of them using a different configuration option, working a little differently. This makes it hard for builders to run unit testing on all modules as they must read and understand each module code and write their build script accordingly. No ones fault, it's the nature of X being distributed in over 240 separate modules. The only mission of the macro is to provide a common configure option (--enable-unit-tests) with a matching ENABLE_UNIT_TESTS variable. Nothing else is planned for this macro. It does not require or depend on XORG_WITH_GLIB or XORG_LD_WRAP. I am not familiar with gtest, it's hard for me to say if --enable-unit-tests would be appropriate. You can look at xserver and libXt as examples of modules using it. The issue is that integration testing usually has different dependencies from unit testing. Unit testing usually has no dependencies, or maybe a dependency on a test framework. However, integration testing usually has dependencies of a working stack. For example, input integration testing for the X server will depend on: xorg-gtest libX11 libXi libutouch-evemu linux root privileges, or special udev rules And development headers for it all. Integration testing for other subsystems would have different stack requirements. One example where builds will want unit tests but not integration tests is package builds. Debian package builds build and run the unit tests during the build and fails the build if the unit tests fail. However, integration tests during debian package builds isn't really feasible without potentially opening security holes. I think unit and integration tests are sufficiently different that a separate configuration option is required. This is what I was hoping for. I assume that this new macro can be used by many other packages, not just xorg-gtest. Would you mind adding the description in the commit text? I'd like to avoid others to randomly pick integration test macro over unit test macro or vice-versa. This is all the documentation we've got, aside from this list. Feel free to push. I'll make a release after I see a few runs on tinderbox. Reviewed-by: Gaetan Nadonmems...@videotron.ca I've pushed it. Please review my last two patches on the list before releasing 1.17.0. They are required for proper
Re: [PATCH video-vmware] config: include saa and vmwgfx subdirs in the tarball
On Mon, Mar 12, 2012 at 20:01:00 +0100, Arkadiusz Miśkiewicz wrote: On Monday 12 of March 2012, Gaetan Nadon wrote: -SUBDIRS = @VMWGFX_DIRS@ src man vmwarectrl +# Order: vmwgfx before src +SUBDIRS = man saa vmwgfx src vmwarectrl make -j X will not obey this order. I'm pretty sure that's not true. Cheers, Julien ___ 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
Re: [PATCH video-vmware] config: include saa and vmwgfx subdirs in the tarball
On 12-03-12 03:12 PM, Jakob Bornecrantz wrote: - Original Message - Use AM_CONDITIONAL. Automake knows what to distribute. It needs to be able to navigate down the subdirs to find what needs to be included in the tarball. To test reliably, create a tarball and expand it into a separate directory and build with xatracker. Distcheck will not detect missing code when such code is configured not to build. The content of a tarball *must* always be identical, regardless of the configuration options used or on which platform it was configured. Signed-off-by: Gaetan Nadon mems...@videotron.ca Thanks, I had just done a simpler patch, but less correct then yours, so I'll rather use this. Do we really need to do the conditional in all the Makefile.am's according to the link below that isn't needed and it will figure out DIST_SUBDIRS correctly? No, not really. Like any coding job, there are different ways of doing it with different pros and cons. These are some of the experiences I had which influence my choices: Developers often end-up in a Makefile without having gone through configure.ac, hence they don't know statements in there that might affect the Makefile. They would not even notice that vmwglx is conditionally compiled. One may invoke make from the vmwglx subdir on a system that does not have the xatracker and waste time chasing ghost problems. It's confusing when 'make' does not behave the same when invoked from subdirs. The /src makefile still needs a conditional. It can be done through configure.ac but that increases this file complexity. I can see cases where a conditional SUBDIRS would be preferable. Over time you get used to do it one way over the other. There is really nothing wrong, feel free to change it. BTW, saa can always be built, right? That would help finding compiler errors and be subject to distcheck verification. That would leave us with just the vmwglx subdir to be conditionally skipped. Also, if you feel like it, AC_SYS_LARGEFILE does not really need to be in a condition. It's harmless and can go with other AC_ statements at the top in the Initialize Autoconf section. Thanks! http://www.gnu.org/software/automake/manual/html_node/Subdirectories-with-AM_005fCONDITIONAL.html Cheers, Jakob. --- Makefile.am|4 +++- configure.ac | 18 ++ saa/Makefile.am|4 +++- src/Makefile.am|7 +-- vmwgfx/Makefile.am |6 +++--- 5 files changed, 20 insertions(+), 19 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1203715..64c019e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,9 @@ # IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -SUBDIRS = @VMWGFX_DIRS@ src man vmwarectrl +# Order: vmwgfx before src +SUBDIRS = man saa vmwgfx src vmwarectrl + MAINTAINERCLEANFILES = ChangeLog INSTALL .PHONY: ChangeLog INSTALL diff --git a/configure.ac b/configure.ac index cf1491f..af2737a 100644 --- a/configure.ac +++ b/configure.ac @@ -120,29 +120,23 @@ DRIVER_NAME=vmware AC_SUBST([DRIVER_NAME]) AC_MSG_CHECKING([whether to build Kernel Mode Setting and 3D]) -VMWGFX_DIRS= if test x$BUILD_VMWGFX = xyes; then AC_MSG_RESULT([yes]) AC_SYS_LARGEFILE -VMWGFX_DIRS=saa vmwgfx -VMWGFX_LIBADD='$(top_builddir)/vmwgfx/libvmwgfx.la' -AC_CONFIG_FILES([ -saa/Makefile -vmwgfx/Makefile -]) -AC_DEFINE([BUILD_VMWGFX], 1, - [Building the vmwgfx driver path]) +AC_DEFINE([BUILD_VMWGFX], 1, [Building the vmwgfx driver path]) else AC_MSG_RESULT([no]) fi -AC_SUBST([VMWGFX_DIRS]) -AC_SUBST([VMWGFX_LIBADD]) +AM_CONDITIONAL(BUILD_VMWGFX, test x$BUILD_VMWGFX = xyes) + AC_CONFIG_FILES([ Makefile +man/Makefile +saa/Makefile +vmwgfx/Makefile src/Makefile vmwarectrl/Makefile -man/Makefile ]) AC_OUTPUT diff --git a/saa/Makefile.am b/saa/Makefile.am index 849ced9..48c9734 100644 --- a/saa/Makefile.am +++ b/saa/Makefile.am @@ -1,3 +1,5 @@ + +if BUILD_VMWGFX noinst_LTLIBRARIES = libsaa.la libsaa_la_CFLAGS = $(CWARNFLAGS) $(XORG_CFLAGS) @@ -10,4 +12,4 @@ libsaa_la_SOURCES = \ saa_render.c \ saa_accel.c \ saa.h - +endif diff --git a/src/Makefile.am b/src/Makefile.am index 1f54168..04c9e0d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -28,8 +28,11 @@ vmware_drv_la_LTLIBRARIES = vmware_drv.la vmware_drv_la_LDFLAGS = -module -avoid-version vmware_drv_la_CFLAGS = $(CWARNFLAGS) @XORG_CFLAGS@ vmware_drv_ladir = @moduledir@/drivers -vmware_drv_la_LIBADD = @VMWGFX_LIBADD@ -vmware_drv_la_DEPENDENCIES = @VMWGFX_LIBADD@ + +if BUILD_VMWGFX +vmware_drv_la_LIBADD = $(top_builddir)/vmwgfx/libvmwgfx.la
Re: [PATCH macros 1/2] Fix cflag test compiler message and cache ids
On 12-03-12 02:57 PM, Chase Douglas wrote: When the language is C++, the flag checking message references $CC instead of $CXX. The cache id is also xorg_cv_cc_* instead of xorg_cv_cxx_*. This change fixes both issues. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- xorg-macros.m4.in |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index ee356e1..2da57c2 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1503,9 +1503,13 @@ AC_LANG_CASE( [C], [ AC_REQUIRE([AC_PROG_CC_C99]) define([PREFIX], [C]) + define([CACHE_PREFIX], [cc]) + define([COMPILER], [$CC]) ], [C++], [ define([PREFIX], [CXX]) + define([CACHE_PREFIX], [cxx]) + define([COMPILER], [$CXX]) ] ) @@ -1550,8 +1554,8 @@ m4_foreach([flag], m4_cdr($@), [ PREFIX[FLAGS]=$PREFIX[FLAGS] ]flag[ dnl Some hackery here since AC_CACHE_VAL can't handle a non-literal varname - AC_MSG_CHECKING([if $CC supports ]flag[]) - cacheid=`AS_ECHO([xorg_cv_cc_flag_]flag[])` + AC_MSG_CHECKING([if ]COMPILER[ supports]flag[]) + cacheid=`AS_ECHO([xorg_cv_]CACHE_PREFIX[_flag_]flag[])` AC_CACHE_VAL(AS_TR_SH($cacheid), [AC_LINK_IFELSE([AC_LANG_PROGRAM([int i;])], [eval AS_TR_SH($cacheid)=yes], Either this patch or Jon Turney's patch will need to be rebased due to the removal of AS_ECHO. http://lists.x.org/archives/xorg-devel/2012-March/029738.html Reviewed-by: Gaetan Nadonmems...@videotron.ca ___ 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
Re: [PATCH macros 2/2] Separate unknown warning options by language
On 12-03-12 02:57 PM, Chase Douglas wrote: If XORG_COMPILER_FLAGS is called more than once with separate languages, the unknown warning options used internally for unknown warning checking will be set the first time and then the cached value will be used for subsequent languages. This is a problem if the compilers differ between the languages. This change ensures that the unknown warning options are namespaced so multiple XORG_COMPILER_FLAGS calls with different languages are checked separately. Signed-off-by: Chase Douglas chase.doug...@canonical.com --- xorg-macros.m4.in | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 2da57c2..0d8a754 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1515,28 +1515,28 @@ AC_LANG_CASE( [xorg_testset_save_]PREFIX[FLAGS]=$PREFIX[FLAGS] -if test x$xorg_testset_unknown_warning_option = x ; then +if test x$[xorg_testset_]CACHE_PREFIX[_unknown_warning_option] = x ; then PREFIX[FLAGS]=$PREFIX[FLAGS] -Werror=unknown-warning-option - AC_CACHE_CHECK([if compiler supports -Werror=unknown-warning-option], - xorg_cv_compiler_flag_unknown_warning_option, + AC_CACHE_CHECK([if ]COMPILER[ supports -Werror=unknown-warning-option], + [xorg_cv_]CACHE_PREFIX[_flag_unknown_warning_option], AC_COMPILE_IFELSE([AC_LANG_SOURCE([int i;])], - [xorg_cv_compiler_flag_unknown_warning_option=yes], - [xorg_cv_compiler_flag_unknown_warning_option=no])) - xorg_testset_unknown_warning_option=$xorg_cv_compiler_flag_unknown_warning_option + [xorg_cv_]CACHE_PREFIX[_flag_unknown_warning_option=yes], + [xorg_cv_]CACHE_PREFIX[_flag_unknown_warning_option=no])) + [xorg_testset_]CACHE_PREFIX[_unknown_warning_option]=$[xorg_cv_]CACHE_PREFIX[_flag_unknown_warning_option] PREFIX[FLAGS]=$[xorg_testset_save_]PREFIX[FLAGS] fi -if test x$xorg_testset_unused_command_line_argument = x ; then - if test x$xorg_testset_unknown_warning_option = xyes ; then +if test x$[xorg_testset_]CACHE_PREFIX[_unused_command_line_argument] = x ; then + if test x$[xorg_testset_]CACHE_PREFIX[_unknown_warning_option] = xyes ; then PREFIX[FLAGS]=$PREFIX[FLAGS] -Werror=unknown-warning-option fi PREFIX[FLAGS]=$PREFIX[FLAGS] -Werror=unused-command-line-argument - AC_CACHE_CHECK([if compiler supports -Werror=unused-command-line-argument], - xorg_cv_compiler_flag_unused_command_line_argument, + AC_CACHE_CHECK([if ]COMPILER[ supports -Werror=unused-command-line-argument], + [xorg_cv_]CACHE_PREFIX[_flag_unused_command_line_argument], AC_COMPILE_IFELSE([AC_LANG_SOURCE([int i;])], - [xorg_cv_compiler_flag_unused_command_line_argument=yes], - [xorg_cv_compiler_flag_unused_command_line_argument=no])) - xorg_testset_unused_command_line_argument=$xorg_cv_compiler_flag_unused_command_line_argument + [xorg_cv_]CACHE_PREFIX[_flag_unused_command_line_argument=yes], + [xorg_cv_]CACHE_PREFIX[_flag_unused_command_line_argument=no])) + [xorg_testset_]CACHE_PREFIX[_unused_command_line_argument]=$[xorg_cv_]CACHE_PREFIX[_flag_unused_command_line_argument] PREFIX[FLAGS]=$[xorg_testset_save_]PREFIX[FLAGS] fi Reviewed-by: Gaetan Nadonmems...@videotron.ca ___ 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
[PATCH 4/5] Xext: donate an 'r' to the poor sync developers
luckily my keyboard seems to have plenty of spare ones. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Xext/syncsrv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h index 609ecc6..3573fe9 100644 --- a/Xext/syncsrv.h +++ b/Xext/syncsrv.h @@ -126,7 +126,7 @@ extern pointer SyncCreateSystemCounter( ); extern void SyncChangeCounter( -SyncCounter * pCounte, +SyncCounter *pCounter, CARD64 new_value ); -- 1.7.7.6 ___ 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
[PATCH 5/5] Xext: SyncCreateSystemCounter returns a SyncCounter*
type safety++
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xext/sync.c|2 +-
Xext/syncsrv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 002d40e..7791ab6 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -969,7 +969,7 @@ static int FreeCounter(void *, XID);
* * System Counter utilities
*/
-pointer
+SyncCounter*
SyncCreateSystemCounter(
const char *name,
CARD64 initial,
diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
index 3573fe9..0e26b2d 100644
--- a/Xext/syncsrv.h
+++ b/Xext/syncsrv.h
@@ -116,7 +116,7 @@ typedef union {
SyncAwait await;
} SyncAwaitUnion;
-extern pointer SyncCreateSystemCounter(
+extern SyncCounter* SyncCreateSystemCounter(
const char *name,
CARD64 inital_value,
CARD64 resolution,
--
1.7.7.6
___
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
Re: [PATCH 3/5] Xext: remove needless /* parameter */ comments in declaration
On 03/12/12 04:20 PM, Peter Hutterer wrote: +CARD64 inital_value, Should that be initial? +CARD64 resolution, +SyncCounterType counterType, SyncSystemCounterQueryValue QueryValue, SyncSystemCounterBracketValues BracketValues ); extern void SyncChangeCounter( -SyncCounter * /* pCounter*/, -CARD64 /* new_value */ +SyncCounter * pCounte, +CARD64 new_value Shouldn't you just merge patch 4 with this instead of introducing a typo in one patch and fixing in the next? -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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
Re: [PATCH 3/5] Xext: remove needless /* parameter */ comments in declaration
On Mon, Mar 12, 2012 at 05:10:39PM -0700, Alan Coopersmith wrote: On 03/12/12 04:20 PM, Peter Hutterer wrote: +CARD64 inital_value, Should that be initial? yes, I'll fix it up, thanks. +CARD64 resolution, +SyncCounterType counterType, SyncSystemCounterQueryValue QueryValue, SyncSystemCounterBracketValues BracketValues ); extern void SyncChangeCounter( -SyncCounter * /* pCounter*/, -CARD64 /* new_value */ +SyncCounter * pCounte, +CARD64 new_value Shouldn't you just merge patch 4 with this instead of introducing a typo in one patch and fixing in the next? whoops, i could've sworn the typo was there to begin with. how embarrassing. I'll squash them together. thanks. Cheers, Peter ___ 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
[PATCH v2 3/5] Xext: remove needless /* parameter */ comments in declaration
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes to v1:
- typo fix inital → initial
- This replaces 4/5, typo originally fixed by 4/5 was introduced by me
Xext/syncsrv.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
index 431dec3..21587a6 100644
--- a/Xext/syncsrv.h
+++ b/Xext/syncsrv.h
@@ -117,17 +117,17 @@ typedef union {
} SyncAwaitUnion;
extern pointer SyncCreateSystemCounter(
-const char */* name */,
-CARD64 /* inital_value */,
-CARD64 /* resolution */,
-SyncCounterType /* change characterization */,
+const char *name,
+CARD64 initial_value,
+CARD64 resolution,
+SyncCounterType counterType,
SyncSystemCounterQueryValue QueryValue,
SyncSystemCounterBracketValues BracketValues
);
extern void SyncChangeCounter(
-SyncCounter * /* pCounter*/,
-CARD64 /* new_value */
+SyncCounter *pCounter,
+CARD64 new_value
);
extern void SyncDestroySystemCounter(
--
1.7.7.6
___
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
[PATCH synaptics 1/3] Always require mtdev on eventcomm
Since a missing mtdev disables all of multitouch on eventcomm, we might as
well always require it.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
configure.ac|5 +
src/eventcomm.c | 26 +-
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/configure.ac b/configure.ac
index 62f6ace..29f6e68 100644
--- a/configure.ac
+++ b/configure.ac
@@ -124,10 +124,7 @@ if test x$BUILD_EVENTCOMM = xyes; then
if test x$HAVE_XI22 = xyes; then
# Obtain compiler/linker options for mtdev
-PKG_CHECK_MODULES(MTDEV, mtdev, HAVE_MTDEV=yes, HAVE_MTDEV=no)
-fi
-if test x$HAVE_XI22 = xyes test x$HAVE_MTDEV = xyes; then
-AC_DEFINE(HAVE_MTDEV, 1, [MTDev available])
+PKG_CHECK_MODULES(MTDEV, mtdev)
fi
fi
if test x$BUILD_PSMCOMM = xyes; then
diff --git a/src/eventcomm.c b/src/eventcomm.c
index 2556fcb..8904851 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -41,7 +41,7 @@
#include synaptics.h
#include synapticsstr.h
#include xf86.h
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
#include mtdev.h
#endif
@@ -69,7 +69,7 @@ struct eventcomm_proto_data
double st_to_mt_scale_x;
int st_to_mt_offset_y;
double st_to_mt_scale_y;
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
struct mtdev *mtdev;
int axis_map[MT_ABS_SIZE];
int cur_slot;
@@ -92,7 +92,7 @@ EventProtoDataAlloc(void)
return proto_data;
}
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
static int
last_mt_vals_slot(const SynapticsPrivate *priv)
{
@@ -197,7 +197,7 @@ EventDeviceOnHook(InputInfoPtr pInfo, SynapticsParameters
*para)
proto_data-need_grab = FALSE;
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
InitializeTouch(pInfo);
#endif
@@ -207,7 +207,7 @@ EventDeviceOnHook(InputInfoPtr pInfo, SynapticsParameters
*para)
static Bool
EventDeviceOffHook(InputInfoPtr pInfo)
{
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
UninitializeTouch(pInfo);
#endif
@@ -411,7 +411,7 @@ event_query_axis_ranges(InputInfoPtr pInfo)
priv-minw, priv-maxw,
NULL, NULL);
-#if HAVE_MTDEV
+#if HAVE_MULTITOUCH
if (priv-has_touch)
{
int st_minx = priv-minx;
@@ -500,14 +500,14 @@ EventQueryHardware(InputInfoPtr pInfo)
static Bool
SynapticsReadEvent(InputInfoPtr pInfo, struct input_event *ev)
{
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
struct eventcomm_proto_data *proto_data = priv-proto_data;
#endif
int rc = TRUE;
ssize_t len;
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
if (proto_data-mtdev)
len = mtdev_get(proto_data-mtdev, pInfo-fd, ev, 1) *
sizeof(struct input_event);
@@ -531,7 +531,7 @@ static void
EventProcessTouchEvent(InputInfoPtr pInfo, struct SynapticsHwState *hw,
struct input_event *ev)
{
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
struct eventcomm_proto_data *proto_data = priv-proto_data;
@@ -709,7 +709,7 @@ static int EventDevOnly(const struct dirent *dir) {
return strncmp(EVENT_DEV_NAME, dir-d_name, 5) == 0;
}
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
static void
event_query_touch(InputInfoPtr pInfo)
{
@@ -841,14 +841,14 @@ EventReadDevDimensions(InputInfoPtr pInfo)
{
SynapticsPrivate *priv = (SynapticsPrivate *)pInfo-private;
struct eventcomm_proto_data *proto_data = priv-proto_data;
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
int i;
#endif
proto_data = EventProtoDataAlloc();
priv-proto_data = proto_data;
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
for (i = 0; i MT_ABS_SIZE; i++)
proto_data-axis_map[i] = -1;
proto_data-cur_slot = -1;
@@ -856,7 +856,7 @@ EventReadDevDimensions(InputInfoPtr pInfo)
if (event_query_is_touchpad(pInfo-fd, (proto_data) ?
proto_data-need_grab : TRUE))
{
-#ifdef HAVE_MTDEV
+#ifdef HAVE_MULTITOUCH
event_query_touch(pInfo);
#endif
event_query_axis_ranges(pInfo);
--
1.7.7.6
___
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
[PATCH synaptics 2/3] Fix build error - duplicate typedef (#47168)
Introduced in c34cf307f9982b62c6e6dfa2687e1b16f527f2a4.
synapticsstr.h includes synproto.h, which now contains the typedef.
X.Org Bug 47168 http://bugs.freedesktop.org/show_bug.cgi?id=47168
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
src/synapticsstr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index d4daeba..92c64fb 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -183,7 +183,7 @@ typedef struct _SynapticsParameters
} SynapticsParameters;
-typedef struct _SynapticsPrivateRec
+struct _SynapticsPrivateRec
{
SynapticsParameters synpara;/* Default parameter settings,
read from
the X config file */
@@ -286,6 +286,6 @@ typedef struct _SynapticsPrivateRec
int *open_slots;/* Array of currently open touch slots
*/
int num_active_touches; /* Number of active touches on device
*/
#endif
-} SynapticsPrivate;
+};
#endif /* _SYNAPTICSSTR_H_ */
--
1.7.7.6
___
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
[PATCH synaptics 3/3] tools: add hysteresis support to synclient
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
tools/synclient.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tools/synclient.c b/tools/synclient.c
index 8d1e8f4..14ec605 100644
--- a/tools/synclient.c
+++ b/tools/synclient.c
@@ -142,6 +142,8 @@ static struct Parameter params[] = {
{AreaRightEdge, PT_INT,0, 1, SYNAPTICS_PROP_AREA,
32, 1},
{AreaTopEdge, PT_INT,0, 1, SYNAPTICS_PROP_AREA,
32, 2},
{AreaBottomEdge,PT_INT,0, 1, SYNAPTICS_PROP_AREA,
32, 3},
+{HorizHysteresis, PT_INT,0, 1,
SYNAPTICS_PROP_NOISE_CANCELLATION, 32, 0},
+{VertHysteresis,PT_INT,0, 1,
SYNAPTICS_PROP_NOISE_CANCELLATION, 32, 1},
{ NULL, 0, 0, 0, 0 }
};
--
1.7.7.6
___
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
Re: [PATCH synaptics 1/3] Always require mtdev on eventcomm
On 03/12/2012 06:34 PM, Peter Hutterer wrote: Since a missing mtdev disables all of multitouch on eventcomm, we might as well always require it. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Works for me. Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ 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
Re: [PATCH synaptics 2/3] Fix build error - duplicate typedef (#47168)
On 03/12/2012 06:34 PM, Peter Hutterer wrote: Introduced in c34cf307f9982b62c6e6dfa2687e1b16f527f2a4. synapticsstr.h includes synproto.h, which now contains the typedef. X.Org Bug 47168 http://bugs.freedesktop.org/show_bug.cgi?id=47168 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net I don't understand why the build didn't fail for me, but this change does look correct. Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ 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
Re: [PATCH synaptics 3/3] tools: add hysteresis support to synclient
On 03/12/2012 06:34 PM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ 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
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #20 from Michel Dänzer mic...@daenzer.net 2012-03-12 05:32:06 PDT --- (In reply to comment #18) I have not yet applied Alex's patch, [...] Have you been able to test it in the meantime? It doesn't seem very likely it'll help, but... However, setting the vramlimit to 64 seems (2 reboots later) to clear up the corruption. vramlimit of 128, 256, and 0 (0 is ignored) each result in corruption Can others affected by the problem confirm this? Can you attach the dmesg output from with and without the working vramlimit? (In reply to comment #19) When switching from tuxracer back to the native desktop mode 1366x768, the pointer was corrupted. [...] Happily the first time a popup happened that covered the cursor for a moment it was restored. Sounds like that was just intermittent corruption of the hardware cursor memory buffer then, e.g. due to a 3D driver bug causing it to be accidentally overridden. Probably not the same problem this report is about. BTW, I am a C programmer... If I knew where to start, I'd love to work on this problem from a code angle. I've looked at the code somewhat, but even in the code specific to my driver there is a lot of code in different places. See e.g. rs690_mc_init() in drivers/gpu/drm/radeon/rs690.c . -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #21 from Alex Deucher ag...@yahoo.com 2012-03-12 06:39:06 PDT --- Might also be related to bug 37679 (interrupt problems). Can you try a similar patch to the ones on that bug? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 47064] no VGA output on Radeon HD6550D when 2 monitors are connected
https://bugs.freedesktop.org/show_bug.cgi?id=47064 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Alex Deucher ag...@yahoo.com 2012-03-12 06:43:07 PDT --- *** This bug has been marked as a duplicate of bug 42490 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 44755] Garbled display on external screen when using 1920x1080 instead of 1920x1200
https://bugs.freedesktop.org/show_bug.cgi?id=44755 --- Comment #10 from Florian Mickler flor...@mickler.org 2012-03-12 15:21:47 PDT --- A patch referencing this bug report has been merged in Linux v3.3-rc7: commit 38aa4a568ba4c3ccba83e862a01e3e60e3b811ee Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Mar 7 19:05:01 2012 -0500 drm/radeon/kms: fix hdmi duallink checks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
