xserver git fails to build with xf86config enabled
The usefulness of it is debatable, i personally don't need it, just wanted to give a heads up. Maarten. libtool: link: ( cd .libs rm -f libxorg.la ln -s ../libxorg.la libxorg.la ) ../../doltlibtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include-I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -DXF86PM -march=k8 -Os -pipe -msse3 -fno-omit-frame-pointer -rdynamic -Wl,-O1 -Wl,--as-needed -Wl,-z,lazy -o Xorg xorg.o libxorg.la -lpciaccess -ldl -ldl -lpthread -lXfont -lXau -lfontenc -lpixman-1 -lhal -ldbus-1 -lXdmcp -lssl -lcrypto -ldl-lm -lrt -lm -lrt libtool: link: x86_64-pc-linux-gnu-gcc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -DXF86PM -march=k8 -Os -pipe -msse3 -fno-omit-frame-pointer -rdynamic -Wl,-O1 -Wl,--as-needed -Wl,-z -Wl,lazy -o .libs/Xorg xorg.o ./.libs/libxorg.a /var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86/parser/.libs/libxf86config.so /usr/lib64/libpciaccess.so -lpthread /usr/lib64/libXfont.so /usr/lib64/libfreetype.so /usr/lib64/libXau.so /usr/lib64/libfontenc.so -lz /usr/lib64/libpixman-1.so /usr/lib64/libhal.so /usr/lib64/libdbus-1.so /usr/lib64/libXdmcp.so -lssl -lcrypto -ldl -lm -lrt ./.libs/libxorg.a(xf86Config.o): In function `xf86ModulelistFromConfig': xf86Config.c:(.text+0x3596): undefined reference to `xf86addNewLoadDirective' xf86Config.c:(.text+0x36a3): undefined reference to `xf86addNewLoadDirective' ./.libs/libxorg.a(xf86Configure.o): In function `DoConfigure': xf86Configure.c:(.text+0xd34): undefined reference to `xf86freeMonitorList' xf86Configure.c:(.text+0xd4c): undefined reference to `xf86freeScreenList' collect2: ld returned 1 exit status make[4]: *** [Xorg] Error 1 make[4]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw' make: *** [all-recursive] Error 1 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-input-evdev: Changes to 'master'
Hi Daniel,
Am Tuesday 02 December 2008 10:13:50 schrieb Daniel Stone:
On Tue, Dec 02, 2008 at 09:21:33AM +0100, Sascha Hlusiak wrote:
Please have a look at xkb/ddxCtrls.c @ XkbDDXUsesSoftRepeat. Software
autorepeat will exactly not happen in the server, if delay is set to 660
and rate is set to 25 (interval=40). This is the default setting when
starting up the server.
Any comments on removing that complete chunk or on setting
XKB_ALWAYS_USES_SOFT_REPEAT?
Hi,
XkbDDXUsesSoftRepeat is pretty weird with checking for the AccessX
flags, but based on a quick look at the XkbProcessKeyEvent flow, I think
it's pretty safe to always just return 1 from XkbDDXUsesSoftRepeat. We
can gut the rest later on, as a continuation of xkb-atkins. I don't
have a clean tree around (am in the middle of a big rebase -i with large
uncommitted changes), but if you or anyone else feels like committing
that, and you've tested that it works:
Signed-off-by: Daniel Stone [EMAIL PROTECTED]
I did some tests and it turned out that commit
6867652c2c8ad563d5655302d94134592b10265b in xf86-input-evdev did not stop the
event from sending repeated events at all. I replaced it with a patch that
just ignores all autorepeated events in evdev. Has the same effect.
And with kicking out the code of xserver, I get completely working and correct
key autorepeat. Delay and rate is correct, default is working as well and
modifiers don't repeat, as expected.
When applying the evdev patch but not the xserver patch, you get non-working
autorepeat when it's set exactly to a delay of 660 and rate of 25 (interval
40), which is the default. I'd rather send the patches to the list first, so
you can decide which branches to commit them to.
Cheers,
Sascha
diff --git a/src/evdev.c b/src/evdev.c
index 7b06c91..d246eed 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -238,15 +238,10 @@ PostKbdEvent(InputInfoPtr pInfo, struct input_event *ev, int value)
int code = ev-code + MIN_KEYCODE;
static char warned[KEY_MAX];
-/* filter repeat events for chording keys */
-if (value == 2
-(ev-code == KEY_LEFTCTRL || ev-code == KEY_RIGHTCTRL ||
- ev-code == KEY_LEFTSHIFT || ev-code == KEY_RIGHTSHIFT ||
- ev-code == KEY_LEFTALT || ev-code == KEY_RIGHTALT ||
- ev-code == KEY_LEFTMETA || ev-code == KEY_RIGHTMETA ||
- ev-code == KEY_CAPSLOCK || ev-code == KEY_NUMLOCK ||
- ev-code == KEY_SCROLLLOCK)) /* XXX windows keys? */
-return;
+/* Filter all repeated events from device.
+ We'll do softrepeat in the server */
+if (value == 2)
+ return;
if (code 255 ev-code KEY_MAX) {
if (!warned[ev-code])
diff --git a/xkb/ddxCtrls.c b/xkb/ddxCtrls.c
index 34ea0bd..be269c2 100644
--- a/xkb/ddxCtrls.c
+++ b/xkb/ddxCtrls.c
@@ -57,27 +57,7 @@ int realRepeat;
int
XkbDDXUsesSoftRepeat(DeviceIntPtr pXDev)
{
-#ifndef XKB_ALWAYS_USES_SOFT_REPEAT
-if (pXDev pXDev-kbdfeed ) {
- if (pXDev-kbdfeed-ctrl.autoRepeat) {
- if (pXDev-key pXDev-key-xkbInfo) {
- XkbDescPtr xkb;
- xkb= pXDev-key-xkbInfo-desc;
- if ((xkb-ctrls-repeat_delay == 660)
- (xkb-ctrls-repeat_interval == 40)
- ((xkb-ctrls-enabled_ctrls(XkbSlowKeysMask|
- XkbBounceKeysMask|
- XkbMouseKeysMask))==0)) {
- return 0;
- }
- return ((xkb-ctrls-enabled_ctrlsXkbRepeatKeysMask)!=0);
- }
- }
-}
-return 0;
-#else
return 1;
-#endif
}
void
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [rant] keeping policy in HAL
Nix wrote: On 1 Dec 2008, David Miller verbalised: A default that, btw, anti-socially totally ignores what people put into their xorg.conf file unless they add yet another knob. That's worse than a default change. What's worse yet is that hal is the single most unstable daemon I have *ever* run on any system I administer. My logs show that for more than half the time over the last two years it has refused to start: it coredumped on startup for a long time, for reasons that changed two or three times as I tracked the development HAL in hopes of it getting fixed, then started working, then some change in 2.6.27 made it freeze on startup: this now seems to be fixed in the stable tree, but, still, robust software this is not. I didn't care enough to track any of these problems down myself because on my fixed-hardware desktop HAL is basically a waste of memory: the hardware doesn't change and I know what I've got. I checked enough to make sure there was a bug reported, then moved on. So I was... somewhat annoyed to discover that when upgrading to xserver 1.5.3 I had to add 'AllowEmptyInput false', particularly given that the option name gives you no clue whatsoever as to why on earth this would make the keyboard reappear, and even the git logs give no rationale. I still have no idea why anyone would consider this behaviour desirable, particularly if you're loading kbd but are not loading evdev. IMHO, if the daemon isn't running at all, AllowEmptyInput should be unnecessary, and kbd/mouse should be consulted if loaded, *whether or not* the server was compiled with HAL support. Anything else is just too prone to failure. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I actually run Xserver-1.5.2 and for my needs it works very well. A try of Xserver-1.5.3 without HAL ended up with a totally unusable system. No screen, no keyboard, no ability to switch back to a text console. Last resort was the reset-button. Same Xserver-1.5.3, this time with HAL and d-bus. Surprise, X11 came up, the keyboard worked, but after a view minutes the system became sluggish. A view into /var/log/messages showed lots of block errors of my system disk and a short time later the system became totally unusable. Again the reset button. The disk is and was 100% ok! Any hints how to prevent HAL from damaging scsi/sata io are welcome. Having had these experiences I think X should not only not rely on HAL, it should never rely on HAL, meaning HAL should be an option. And in its current state, this option should be marked as highly experimental. I would suggest an additional mode of HALD in which it can be started in an non-daemon mode with an filename as argument. In this file HAL should then write what X11 input/output devices it believes to have discovered, best in a notation directly usable for insertion in xorg.conf, and then exit. This way HAL can be developed further without being annoying to users with fixed desktops and/or small systems and xorg.conf stays usable for a reliable configuration. -- Klaus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3Dconnexcion SpacePilot works like a mouse (TrackPoint in laptop)
On Wed, Nov 26, 2008 at 6:13 AM, Jarosław Bułat [EMAIL PROTECTED] wrote: Hello! After connection SpacePilot (3DConnexion) it starts to act as a mouse (TrackPoint), however, it souldn't. SpacePilot is automatically recognized as a mouse. There is no any configuration in /etc/xorg.conf (see Attachment), however, I found the following line in /var/log/Xorg.0.log (see Attachment): (II) config/hal: Adding input device 3Dconnexion SpacePilot (**) 3Dconnexion SpacePilot: always reports core events (**) 3Dconnexion SpacePilot: Device: /dev/input/event6 (II) 3Dconnexion SpacePilot: Found x and y relative axes (II) 3Dconnexion SpacePilot: Found 21 mouse buttons (II) 3Dconnexion SpacePilot: Configuring as mouse (II) XINPUT: Adding extended input device 3Dconnexion SpacePilot (type: MOUSE) (**) 3Dconnexion SpacePilot: YAxisMapping: buttons 4 and 5 (**) 3Dconnexion SpacePilot: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (WW) 3Dconnexion SpacePilot: unable to handle keycode 265 I suspect, HAL did it, see Attachment (lshal.txt). Since I'm using spacenavd from http://spacenav.sourceforge.net/, SpacePilot can't be configured in X server - see FAQ: http://spacenav.sourceforge.net/faq.html. What happened is that HAL saw the device and told the server to use the evdev driver with it. Then evdev went and decided it was a mouse and how to use it based on what the kernel says about its capabilities. How can I disable autoconfiguration for this specific device? If the X Server uses the device as an XInput source, the spacenav driver don't get any events from this device. You can create a fdi file that removes the x11_driver property, which means the X server won't pick it up. Here's what I was doing with the trackpoint on my laptop when evdev didn't work for it: $ cat /etc/hal/fdi/policy/no-hotplug-trackpoint.fdi ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=TrackPoint remove key=input.x11_driver/ /match /device /deviceinfo You'd have to restart HAL for it to recognize these changes. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: MPX window managers?
Hi Peter,
mpwm is dead, and it's for the better. compiz has recently been
picked up and improved:
Thanks for the reply. This is disappointing; the compiz work is an
unreviewed patchset against unspecified versions of compiz and Xorg,
with Xorg patches that the author doesn't plan on submitting upstream.
Can we come up with a plan for a more supportable way to use MPX?
I had a look at the ways in which the metacity branch was failing to
compile, and tried to find out what their current alternatives are:
* XQueryDevicePointer -- remove shared parameter
* XExtendedUngrabDevice -- gone, use XUngrabDevice, add CurrentTime
* XGetPairedPointer -- gone, use attached field of ListInputDevices
* XAllowDeviceEvents -- gone¹, ?
* XQueryWindowAccess -- gone¹, ?
* X{Grab,Ungrab}AccessControl -- gone², ?
Any ideas on how to replace these? Do you think picking up metacity is
a sensible thing to do?
Thanks,
- Chris.
¹:
http://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=f938c524f74fa8828a954bed51d0f3c4c7eb0fad
²:
http://cgit.freedesktop.org/xorg/lib/libXi/commit/?id=447441f4dfdd114ce1f738ccfda097ca1f4d609a
--
Chris Ball [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Multiseated madness
Hi all, I'm using multiseating on an Ubuntu 8.06 Install with X.Org X Server 1.4.0.90. There is currently an issue with Seat1, whereas the screen will appear like this: http://www.flickr.com/photos/[EMAIL PROTECTED]/3077260588/ This usually occurs after some key presses on the keyboard associated with the screen. With this setup, seat0 is a touchscreen with an egalax controller and any mouse plugged into the machine will move the touchscreen pointer. Is there any way to blacklist a mouse from controlling a screen? I am running two sessions with the following graphics cards: 00:0e.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01) [Seat 1, PCI, VGA Interface] 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) [Seat 0 AGP, DVI Interface] xorg.conf ### # Common Section Files FontPath /usr/share/fonts/misc/ FontPath /usr/share/fonts/Type1/ FontPath /usr/share/fonts/100dpi/ FontPath /usr/share/fonts/75dpi/ EndSection Section Module Load dbe # Double buffer extension SubSection extmod Option omit xfree86-dga # don't initialise the DGA extension EndSubSection Load freetype Load glx EndSection ### # Seat 0 Section ServerLayout Identifier Seat0 Screen Screen0 0 0 InputDevice Keyboard0 CoreKeyboard InputDevice EETI SendCoreEvents #InputDevice Mouse0 CorePointer EndSection Section InputDevice Identifier Keyboard0 Driver evdev Option CoreKeyboard Option Device /dev/input/event0 ##Option Device /dev/input/event6 #Option Device /dev/input/by-path/pci-:00:10.0-usb-0:1:1.0-event-kbd Option XkbRules xorg Option XkbModel evdev Option XkbLayout gb EndSection Section InputDevice Identifier EETI Driver egalax Option Device usbauto Option Parameters /var/lib/eeti.param Option ScreenNo 0 EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Deivce /dev/input/mouse1 #Option Device /dev/input/by-path/pci-:00:10.0-usb-0:2:1.0-mouse Option ZAxisMapping 4 5 6 7 Option Emulate3Buttons EndSection Section Device Identifier nvidia-geforce Driver nv BusID PCI:1:0:0 EndSection Section Monitor Identifier Monitor0 HorizSync 31.5 - 79.0 VertRefresh 50.0 - 90.0 EndSection Section Screen Identifier Screen0 Device nvidia-geforce Monitor Monitor0 DefaultDepth 16 SubSection Display Viewport 0 0 Depth 8 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Viewport 0 0 Depth 16 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Viewport 0 0 Depth 24 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection EndSection ### # Seat 1 Section ServerLayout Identifier Seat1 Screen Screen1 0 0 InputDevice Keyboard1 CoreKeyboard InputDevice Mouse1 CorePointer EndSection Section InputDevice Identifier Keyboard1 Driver evdev Option CoreKeyboard ##Option Device /dev/input/event9 Option Device /dev/input/by-path/pci-:00:10.4-usb-0:4.1:1.0-event-kbd Option XkbRules xorg Option XkbModel evdev Option XkbLayout gb EndSection Section InputDevice Identifier Mouse1 Driver mouse Option Protocol auto Option Device /dev/input/by-path/pci-:00:10.4-usb-0:3.4.1:1.0-mouse Option ZAxisMapping 4 5 6 7 Option Emulate3Buttons EndSection Section Device Identifier matrox-mga Driver vesa #Mga driver is buggy! Vesa works fine BusID PCI:0:14:0 EndSection Section Monitor Identifier Monitor1 HorizSync 31.5 - 79.0 VertRefresh 50.0 - 90.0 EndSection Section Screen Identifier Screen1 Device matrox-mga Monitor Monitor1 DefaultDepth 16 SubSection Display Viewport 0 0 Depth 8 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Viewport 0 0 Depth 16 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection SubSection Display Viewport 0 0 Depth 24 Modes 1280x1024 1024x768 800x600 640x480 EndSubSection EndSection gdm.conf-custom [servers] 0=seat0 1=seat1 [server-seat0] name=Seat0 command=/usr/X11R6/bin/X0 -isolateDevice PCI:1:0:0 -sharevts -layout Seat0 flexible=false [server-seat1] name=Seat1 command=/usr/X11R6/bin/X1 -isolateDevice PCI:0:14:0 -sharevts -layout Seat1 flexible=false [greeter] DefaultFace= GlobalFaceDir=/usr/share/pixmaps/ [daemon] AutomaticLoginEnable=true AutomaticLogin=djtouch *lsusb* Bus 005 Device 010: ID 062a:0201 Creative Labs Defender Office Keyboard (K7310) S Zodiak KM-9010 Bus 005 Device 009: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen Bus 005 Device 008: ID 0409:005a NEC Corp. Bus 005 Device 007: ID 0409:005a NEC Corp. Bus 005 Device 001: ID : Bus 004 Device 001: ID : Bus 003 Device 001: ID : Bus 002 Device 001: ID : Bus 001 Device 001: ID : ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ansification of X.Org code: A question how to proceed
Hi Peter, In general, I think everyone agrees conversion of the remaining bits of code that use KR/pre-ANSI-C89 style function prototypes declarations to C89 is a good thing (provided it's done correctly [1]), [1] http://invisible-island.net/ansification/index.html Hi Alan, Adam, Julien, Paulo, now with xorg-macros-1.2 available, I have prepared patches to convert libICE and libSM to strict ANSI C as follows: (1) use xorg-macros-1.2 Use XORG_CHANGELOG for rule to generate ChangeLog from git log Use XORG_CWARNFLAGS for compiler warning flags, leave CFLAGS to user (2) Activate CWARNFLAGS with lots of gcc warnings (3) towards ANSI C make default error handlers and some others static (4) ANSI C convert all old style function declarations == This should then enable and yet avoid `all' compiler (gcc) warnings == The problem is however, that libSM uses _IcePoMagicCookie1Proc and _IcePaMagicCookie1Proc from libSM, but at present they are not declared in an installed header. A similar problem occurs with SnfSetFormat used by app/xfs and declared (but not exported) in libXfont/src/bitmap/snfstr.h I see two possibilities: (A) Declare _IceP[ao]MagicCookie1Proc in the libICE internal header ICElibint.h and repeat (copy) the declaration in libSM, analogous to Paulo's http://bugs.freedesktop.org/show_bug.cgi?id=15082 http://bugs.freedesktop.org/attachment.cgi?id=15213 for SnfSetFormat and xfs This is arguably the worst option :-) Actually, prototypes declared in C sources should be moved to the proper headers. (B) Declare _IceP[ao]MagicCookie1Proc in X11/ICE/ICEmsg.h, bump libICE to 1.0.5, and require 'ice =1.0.5' for libSM X11/ICE/ICEmsg.h contains already prototypes for lots of libICE internal functions _Ice*(). This is I believe, the best option. And while at it, change the calls to iceauth.c:binaryEqual() to memcmp() (or maybe it is done that way to avoid someone somehow LD_PRELOAD'ing memcp ?, but then, one could just LD_PRELOAD libICE ...) (C) There is actually a third possibility: avoid libICE version 1.0.5, and instead test in libSM (via configure) if _IceP[ao]MagicCookie1Proc are declared in X11/ICE/ICEmsg.h and otherwise repeat their declarations. The disadvantage is that this temporary workaround will probably stay there forever. === IMHO possibility (A), and to some extent (C), is against the spirit of [1], but has the advantage to avoid creating a new library version. I would prefer possibility (B), but certainly like to have your opinion on this issue. Solution (B) would also require to move the declaration of SnfSetFormat into a header exported by libXfont (any good idea which one?). X11/fonts/fontmisc.h appears to be most appropriate place, with fontutil.h second, but xfs/os/config.c already include X11/fonts/fontutil.h (but maybe it is also including fontmisc.h indirectly). Once all that has been done, one can attack the real problem with libICE and libSM. They both contain code paths where a macro or function sets a buffer pointer to NULL (e.g., when malloc fails or for an extremely long previous client ID passed to libSM) but this buffer pointer is used subsequently without any test for this condition. with best regards, Peter Breitenlohner [EMAIL PROTECTED] Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: MPX window managers?
'Twas brillig, and Chris Ball at 07/12/08 18:18 did gyre and gimble: Hi Peter, mpwm is dead, and it's for the better. compiz has recently been picked up and improved: Thanks for the reply. This is disappointing; the compiz work is an unreviewed patchset against unspecified versions of compiz and Xorg, with Xorg patches that the author doesn't plan on submitting upstream. I'd speak to Sam directly about that. I'm not sure it's that he doesn't want to submit them upstream, it's just that they are perhaps not appropriate for upstream in their current form. I doubt it's his long term goal to maintain separate patches into the future. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CyberBlade/i7d Dual Head Operation Possible?
On Sat, Dec 6, 2008 at 11:36 PM, Guy Gadola [EMAIL PROTECTED] wrote: Hello, I am trying to configure xorg.conf on a HP Pavilion N3330 to show one instance of X on its tilt-up screen and another instance of X on its external monitor. Currently, the external monitor shows the same content that the screen shows. As far as I know, no one has added dualhead support to the trident driver. IIRC, it works the same as the newer xgi chips, so the xgixp driver should have enough info to figure it out if someone was inclined to add support. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-intel-video-2.5.0::i945::output_TMDS-2_not_found_any_more
hi i have integrated graphics card based on intel 945gm, which has 5 outputs (VGA, LVDS, TMDS-1, TMDS-2 and TV). recently i upgraded intel video driver from version 2.2.1 to version 2.5.0. before upgrade all outputs were found and displayed by xrandr. after upgrade output TMDS-2 was missing. what was the reason to exclude output TMDS-2 ? is there any way to include it back again ? thanx matjaz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] mi: always update the sprite for master devices.
Follow-up to 9ce995373e4a. This re-enables cursor rendering if the MD is controlled through software (e.g. synergy). Reported by John Tapsell: I use Xorg with no mouse attached, but use synergy to control the mouse. The commit means that I no longer have a visible mouse cursor. The mouse cursor is still 'there' in terms that I can click buttons etc with it, but it's just not visible. Signed-off-by: Peter Hutterer [EMAIL PROTECTED] --- mi/mieq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mi/mieq.c b/mi/mieq.c index 971edf9..aef6fae 100644 --- a/mi/mieq.c +++ b/mi/mieq.c @@ -386,7 +386,7 @@ mieqProcessInputEvents(void) } /* Update the sprite now. Next event may be from different device. */ -if (type == DeviceMotionNotify master) +if (type == DeviceMotionNotify (master || dev-isMaster)) miPointerUpdateSprite(dev); } } -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X-server doesn't start after boot-up
i've a debian etch system.. i'm using the grub loader.. immediately after the boot process when the login screen is to take over, instead of the login screen, i get this ... | Hz ? | ... this box keeps moving up and down on the screen.. i'm new to linux so dont know how to configure x by myself.. pls help ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] (server-1.6) Xi: don't update VCP's valuators from DeviceValuator events #18882
The VCP doesn't need to update the valuators anyway since it cannot send XI
events. Just skip that bit.
X.Org Bug 18882 http://bugs.freedesktop.org/show_bug.cgi?id=18882
---
Not cherry-picked from master as master does need to update the valuators.
(Keith: sorry for the resend, wrong From: blocked deliver to the xorg list)
Xi/exevents.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 00a6b21..8eef400 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -781,12 +781,14 @@ UpdateDeviceState(DeviceIntPtr device, xEvent* xE, int
count)
}
/* Update device axis */
-for (i = 1; i count; i++) {
+/* Don't update valuators for the VCP, it never sends XI events anyway */
+for (i = 1; !device-isMaster i count; i++) {
if ((++xV)-type == DeviceValuator) {
int *axisvals;
int first = xV-first_valuator;
BOOL change = FALSE;
+
if (xV-num_valuators
(!v || (xV-num_valuators
(first + xV-num_valuators v-numAxes
@@ -1009,7 +1011,9 @@ ProcessOtherEvent(xEventPtr xE, DeviceIntPtr device, int
count)
}
/* Valuator event handling */
-for (i = 1; i count; i++) {
+/* Don't care about valuators for the VCP, it never sends XI events */
+
+for (i = 1; !device-isMaster i count; i++) {
if ((++xV)-type == DeviceValuator) {
int first = xV-first_valuator;
if (xV-num_valuators
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Intel xf86-intel-video with G45: glxgears synchonised to VSYNC
Hi, I am playing with an Intel G45FC Motherboard with a HDMI connected Samsung HDTV. I am using Fedora 10 as the base with the latest DRM/X11/mesa xf86-intel-video drivers from the Xorg GIT repository. In general this appears to be working. One thing I note however, is that when I run glxgears the 3D drawing frame rate, reported by glxgears, is exactly the VSYNC rate. The CPU usage is well down and is definitely using DRI. When using the stock xf86-intel-video driver that came with Fedora 10, glxgears was reported around 1500. Is this correct behavior, I thought that glxgears simply drew as fast as possible and was not synchronised to the VSYNC frame rate ? Cheers Terry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
