[ANNOUNCE] xf86-input-evdev 2.0.8
Expect this to be the last evdev 2.0.x release. Julien Cristau (1): Fix TestBit() on 64bit Peter Hutterer (1): evdev 2.0.8 git tag: xf86-input-evdev-2.0.8 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.8.tar.bz2 MD5: 7f9ace5bcca1427b0da40827a74cbc33 xf86-input-evdev-2.0.8.tar.bz2 SHA1: 57a88717a621957d82169b7508ef293214f4b952 xf86-input-evdev-2.0.8.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.8.tar.gz MD5: 766876581c436edd3340cdca16c5aeee xf86-input-evdev-2.0.8.tar.gz SHA1: 039880cf19a5031c364e4bcdd8ac9309f1ee932b xf86-input-evdev-2.0.8.tar.gz ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-input-evdev 2.1.0
No blockers reported since the last RC, so let's get it out of the way. The new evdev 2.1 is here, and it's sparkly and shiny and whatnot. Note that this version does not grab the event device anymore. If you're updating from evdev 2.0, ensure you have [1] in the server to avoid events being sent to the TTY. Other patches of interest [2-4] are recommended to avoid duplicate events. Consider the evdev 2.0 branch to be discontinued. The shortlog since RC 3: Fernando Carrijo (1): Fix error message Peter Hutterer (2): Store device file's minor/major to avoid duplicate devices. evdev 2.1 git tag: xf86-input-evdev-2.1.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.1.0.tar.bz2 MD5: a6070ead29b2d81b5b386a96df2661b8 xf86-input-evdev-2.1.0.tar.bz2 SHA1: afa5b981e4205fbefe1a21b95fa973f1c6532142 xf86-input-evdev-2.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.1.0.tar.gz MD5: a4f3cbb67db5374aa5d0ecb8f18c05e1 xf86-input-evdev-2.1.0.tar.gz SHA1: 9599f6219a278a189d830cda374455f585ce294d xf86-input-evdev-2.1.0.tar.gz Cheers, Peter [1] http://cgit.freedesktop.org/xorg/xserver/commit/?id=d936a4235c9625bd41569cef3452dd086284e0d7 [2] http://cgit.freedesktop.org/xorg/xserver/commit/?id=6c451859552e1fc78f6589617482f9ff96d7ed8a [3] http://cgit.freedesktop.org/xorg/xserver/commit/?id=c264826da96ad1859dd112b17eb8aa9e5278478f [4] http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b56b44addc323a00eb7cd86240cb0dd4275bcf8 pgppQDcaZctXX.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Making one multiseat user able to switch vts?
On Tuesday 18 November 2008 04:50:33 you wrote: Kārlis Repsons escreveu: In general it would be nice, if multiseat workstation administrator could switch to vt[1-6]. Does Xorg support it somehow and is it possible to implement (well, kindly ask someone to do it) such option? Otherwise multiseat on Linux is quite problematic, if no ssh is used... (also I noticed a problem with multiseat, that, if I stop X and login manager permanently, I still could not switch to any vts) It's complicated. Pci-rework, through libpciaccess, cleaned a bunch of the mess that was living in our server. But that wasn't good enough. There's still some issues that don't let us remove the entirely Xorg's pci layer. And this is the point: there's a lot of pci users (VGACon, framebuffer, Xorg and possibly others) in your system fighting for the same piece of hardware. With lucky the kernel based modesetting will let the code more nice and trivial to remove more things from the server. Dave obtained a very nice demo recently starting a rootless X server. So is that kind of work in progress or will never be fixed? Cheers, PS: really, try to avoid a single machine to configure your multiseat box. No one needs text console in our current world. Well, this far I have two options: ssh or restart with console framebuffer-enabled kernel and other X settings, both of which are cumbersome solutions for dualseat. Can I ask one more thing: what is causing those problems with console framebuffer on x86_64? If that thing is in kernel, I get messed-up screen time after time and console cursor blinking on primary video device constantly... Regards ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] RFC: Add XF86XK_Suspend and XF86XK_Hibernate keysym defs.
On Tue, Nov 18, 2008 at 10:03:57AM +, Richard Hughes wrote: On Mon, 2008-10-27 at 16:36 +1030, Peter Hutterer wrote: At the moment, we have the following keysyms defined to put a computer into a sleep state: XF86XK_Standby0x1008FF10 /* System into standby mode */ XF86XK_PowerDown 0x1008FF21 /* Deep sleep the system */ XF86XK_Sleep 0x1008FF2F /* Put system to sleep*/ Proposed change by Richard Hughes: The nomenclature I've been trying to make stick (most projects now use this) for a few years now is: standby: high sleep state, nobody uses this any more hibernate: sleep to disk - slow, but can remove power suspend: sleep to ram - fast, but can't remove power hybrid sleep: sleep to both, slow, and can remove power, but quick to resume if you don't - most users don't use this This patch adds XF86XK_Suspend and XF86XK_Hibernate. The behaviour of XF86XK_Sleep can then be configured on a per-session basis. [...] If there are no objections, could this patch please be merged? If the patch is pushed, then we can de-insane some of the XOrg-session mappings and then the only crazy thing left to patch is the kernel. already pushed. http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=1e7d4dd151da4f0898a86608a1ee67588163 I'll put that and the matching libX11 patch into Fedora tomorrow. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Intel driver accesses reserved register bit SDVOC/SDVO_DETECTED
Using the intel driver on a GM45 device, with monitors connected to the TMDS1/2 outputs, it was found that the xserver was refusing to accept the option option Monitor-TMDS-2 monitor-id and also leaving the second screen rather blank. Eventually, it was found that at xf86-video-intel::src/i830_driver.c, function I830SetupOutputs, line 922, the register SDVOC is anded with the SDVO_DETECTED mask in order to detect if a monitor was connected at startup. This register bit was clear, causing the screen to be missed. A careful reading of the intel documentation shows that while this bit indicates an initially detected connected monitor for SDVOB, in fact it is reserved in the SDVOC register, and should therefore be ignored. So to cause the second monitor to be enabled, the option ForceSDVODetect, false by default, should be set to true. Perhaps consideration could be given to defaulting this option to true, or even ignoring such initialization bits as SDVO_DETECTED altogether. Cheers. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
On Mon, Nov 17, 2008 at 8:54 PM, Peter Hutterer [EMAIL PROTECTED] wrote: On Mon, Nov 17, 2008 at 11:25:25AM -0800, Dan Nicholson wrote: I decided to take a crack at moving xkbcomp into the server so it's not popen'd whenever a keymap is loaded. For the first crack, I'm trying to just leave xkbcomp pretty much unchanged except for the interface. What's causing me the most difficulty is converting to server API. One snag I've hit is XStringToKeysym. Here's an example usage in the xkbcomp parser: As much as I'd like to see it in the server - is the popen the painful bit? AFAIU, the current approach goes from RMLVO to Kkcstg to xkb to xkm, every time we call InitKeyboardDeviceStruct. I agree completely. As soon as I looked at the path taken in XkbDDXNamesFromRules, I realized how insane it was that there were all these conversions. I'm just moving one step at a time here, with the first one being: leave the retarded conversion path in place, but move the converter into the server. The next step would be to actually start removing parts of the conversion process, but that will take a little more effort. Ideally, we'd like to cache and re-use as much as possible. Usually, all keyboards come up with the same map anyway and compiling it again is redundant. Just doing that might already save a significant chunk of time. This should also be much easier to achieve, and if it provides a relevant speedup it would be great as interim solution. I'll try to look at that. So the path is XkbInitKeyboardDeviceStruct:xkb/xkbInit.c - XkbDDXNamesFromRules:xkb/ddxLoad.c this is where all the rules parsing happens, skipping that may save time. - XkbDDXLoadKeymapByNames:xkb/ddxLoad.c this is where xkbcomp is called with the Kcstg format. xkbcomp now parses that into an xkm format - XkmReadFile:xkb/xkmread.c here we read in the compiled keymap and basically copy it into the internal structs. Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. Seem reasonable? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Export a bunch of matrix operations from render.
Keith Packard [EMAIL PROTECTED] writes: The render extension uses many matrix operations internally, this change exposes those functions to other parts of the server, drivers and extensions. The change is motivated by the 'transform' additions to the RandR extension but will likely be useful elsewhere. Can we put these in pixman and add a dependency instead? pixman_transform_point3d is already there; the only reason I left it in the server was for ABI reasons. Soren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
On Mon, Nov 17, 2008 at 9:17 PM, Alan Coopersmith [EMAIL PROTECTED] wrote: Dan Nicholson wrote: One snag I've hit is XStringToKeysym. Is there an equivalent API in the server to do this conversion? I haven't checked if there's one added now, but I know our Xsun pre-xkb keytable parser linked in a copy of the ks_tables.h file built in the libX11 build and included a static copy of the XStringToKeysym function to do the lookups in it. Cool, that's what I thought of a little later. However, bringing XStringToKeysym right in would also mean the Xrm hash table used for the keysymdb. That seemed a little to nasty. Then I thought it might work to construct a static table from XKeysymDB and then dump it into some other lookup structure already in the server. Can the hash table API in dix/resources.c be used, or does that tie into the resources system more deeply. I wonder if going forward, moving XStringToKeysym into a separate library, or putting equivalent functionality in something like libxcb-keysyms wouldn't be a better way, to reduce duplication of this data/parsing code needed by users of both libX11 libxcb, and the Xserver itself. Not a bad idea. Nearly everything I've done so far has introduced duplication from the client side, but I figured I'd try to get it working before moving orthogonally. It's certainly easier to implement everything internally to the server rather than introducing a bunch of external API that might be wrong and can't be removed later. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
On Tue, Nov 18, 2008 at 03:44:32AM -0800, Dan Nicholson wrote: I agree completely. As soon as I looked at the path taken in XkbDDXNamesFromRules, I realized how insane it was that there were all these conversions. I'm just moving one step at a time here, with the first one being: leave the retarded conversion path in place, but move the converter into the server. The next step would be to actually start removing parts of the conversion process, but that will take a little more effort. I think it'd be less effort to leave the converter as-is and remove the need for calling it, but that's a guess only too. So the path is XkbInitKeyboardDeviceStruct:xkb/xkbInit.c - XkbDDXNamesFromRules:xkb/ddxLoad.c this is where all the rules parsing happens, skipping that may save time. - XkbDDXLoadKeymapByNames:xkb/ddxLoad.c this is where xkbcomp is called with the Kcstg format. xkbcomp now parses that into an xkm format - XkmReadFile:xkb/xkmread.c here we read in the compiled keymap and basically copy it into the internal structs. Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. right, you'd go from oh, same RMLVO to xkmRead() directly. In theory, you could just memcpy the structs from another device but that's not a task for the faint-hearted. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Dual Head DVI on Q965/Q963 Express Chipset Family
hi, i tried to get my kubuntu (newest version) running in dual head mode. i have a fujitsu siemens celsius w350 workstation with the Q965/Q963 chipset on board. additional i have a add2 card which gives me 2 dvi ports. the drivers installed are the newest from kubuntu (2:2.4.1), but i just can't get my xserver so recognize the two dvi outputs. xrandr tells me about one vga connector (on board) and one tmds connector, but never sees the second dvi connector. would be great if anybody knew a solution for this.. cheers, hannes begin:vcard fn:Hannes Mezger n:Mezger;Hannes org:ascolab GmbH adr:;;Am Weichselgarten 7;Erlangen;;91058;Germany email;internet:[EMAIL PROTECTED] tel;work:+49 9131 691 124 tel;fax:+49 9131 691 128 tel;cell:+49 171 8115522 note;quoted-printable:Handelsregister/Commercial Register: Amtsgericht F=C3=BCrth HRB 9360=0D=0A= Gesch=C3=A4ftsf=C3=BChrer/Managing Directors: Gerhard Gappmeier, Matthias= Damm, Uwe Steinkrau=C3=9F url:www.ascolab.com version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP / Gnome / KDE / Data transfer / GTK QT / Xorg extension
Le 12/11/2008 22:54, Jean-Francois Bouchard a écrit : Problem : We experience very slow scroll speed (lets say, cat /var/log/messages) in Gnome terminal via XDMCP. (1M file : 1.5 minute to display) [snip] On the fat server ... X Protocol Version 11, Revision 0, Release 6.8.2 Kernel 2.6.9-78.0.1.ELsmp Gnome 2.8 ^^^ That's your problem, right there. vte as shipped in Gnome 2.8 was very slow and major performance profiling was done later on (in 2.12 or 2.14, I'm not sure). You should definitely try to update your fat server to a more recent Gnome stack. It might not be perfect and there's probably some more room left for improvements, but I think you'll find it a huge win over what you are currently using. Cheers Rémi Cardon Hello, Thats very interesting. For sure we will go forward and upgrade our version. But the main problem here is the difference between a thin client with Centos 4.3 and Ubuntu 8.10. Test : On the same hardware, same network cable. Centos 4.2 default install. Only changed the inittab file to X -query my server. Ubuntu 8.10 default install. No change, I use the GDM button to query my X server. Same Fat client. Using Terminal (Gnome) by opening, maximizing (total window size : a bit less then 1600x1200) the terminal and typing the command : sudo time cat /var/log/secure.1 (file of 12819215 bytes) on both machines. I obtain : Centos 4.3 (in real) : 10.71 10.52 10.51 Ubuntu 8.10 (in real) : 20.58 20.24 20.23 Note that the experience with Ubuntu 8.10 seems much more sluggish (we see blocks of bitmaps moving). Note that with Ubuntu 8.04, the performance is better but never at the level of Centos 4.3. Note also that in both case, Konsole is blazing fast (display under 2sec). Note that both install were using the radeon driver. Thank you for you thought. -- Jean-Francois Bouchard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
Peter Hutterer wrote: On Tue, Nov 18, 2008 at 03:44:32AM -0800, Dan Nicholson wrote: I agree completely. As soon as I looked at the path taken in XkbDDXNamesFromRules, I realized how insane it was that there were all these conversions. I'm just moving one step at a time here, with the first one being: leave the retarded conversion path in place, but move the converter into the server. The next step would be to actually start removing parts of the conversion process, but that will take a little more effort. A bit offtopic, but I think xkb really lacks a tool like xkeycaps http://www.jwz.org/xkeycaps/ Xkb configuration is not something trivial, and a program like that would be very useful. But I think the right path should be not move xkbcomp to the X Server, at least not without a major xkb redesign, instead, have an external tool (xkbcomp) generate pre compiled keymaps based on a brief description. I think it'd be less effort to leave the converter as-is and remove the need for calling it, but that's a guess only too. So the path is XkbInitKeyboardDeviceStruct:xkb/xkbInit.c - XkbDDXNamesFromRules:xkb/ddxLoad.c this is where all the rules parsing happens, skipping that may save time. - XkbDDXLoadKeymapByNames:xkb/ddxLoad.c this is where xkbcomp is called with the Kcstg format. xkbcomp now parses that into an xkm format - XkmReadFile:xkb/xkmread.c here we read in the compiled keymap and basically copy it into the internal structs. Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. right, you'd go from oh, same RMLVO to xkmRead() directly. In theory, you could just memcpy the structs from another device but that's not a task for the faint-hearted. Cheers, Peter Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mouse button problems using Logitech NX80
Dne ponedeljek 17. novembra 2008 je Peter Hutterer napisal(a): please file a bug report, because the information is getting spread across too many emails now and I'm losing track. Done. :) xf86-input-evdev 2.0.99.3 and HAL mouse button mapping (and HWheel) problem: https://bugs.freedesktop.org/show_bug.cgi?id=18596 xf86-input-synaptics (0.15.2 and 0.99.1) and HAL ignores all settings in .fdi: https://bugs.freedesktop.org/show_bug.cgi?id=18597 Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 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: [PATCH] Export a bunch of matrix operations from render.
On Tue, 2008-11-18 at 12:53 +0100, Soeren Sandmann wrote: Can we put these in pixman and add a dependency instead? pixman_transform_point3d is already there; the only reason I left it in the server was for ABI reasons. I'm not sure we want to expose the fixed point versions. -- [EMAIL PROTECTED] 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: Moving xkbcomp into the server
Le mardi 18 novembre 2008 à 13:36 -0200, Paulo Cesar Pereira de Andrade A bit offtopic, but I think xkb really lacks a tool like xkeycaps http://www.jwz.org/xkeycaps/ Xkb configuration is not something trivial, and a program like that would be very useful. Like this? http://simos.info/blog/archives/747 Interested people can help Simos polish his summer of code project. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/7] Updated enter/leave event model
On Fri, 2008-11-14 at 20:51 +1000, [EMAIL PROTECTED] wrote: This patch series updates the X server to the enter/leave event model proposed by Owen Taylor a few months back [1]. Instead of the current model where some Enter or Leave events are only suppressed, this model actually adjusts each model to be true for a local scope. This only applies to core events, device events are still being sent unconditionally. Note that this patch was one big patch split up into multiple ones to ease review. While each patch compiles, I haven't tested them separately. Also, more testing is needed (especially the grab cases) before it can go upstream but I'd appreciate any early review. I don't see any obvious problems with this. - ajax 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: Moving xkbcomp into the server
On Tue, Nov 18, 2008 at 4:28 AM, Peter Hutterer [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 03:44:32AM -0800, Dan Nicholson wrote: I agree completely. As soon as I looked at the path taken in XkbDDXNamesFromRules, I realized how insane it was that there were all these conversions. I'm just moving one step at a time here, with the first one being: leave the retarded conversion path in place, but move the converter into the server. The next step would be to actually start removing parts of the conversion process, but that will take a little more effort. I think it'd be less effort to leave the converter as-is and remove the need for calling it, but that's a guess only too. So, I took a look at this, and it was fairly easy to write an (untested) patch that checks if RMLVO has been changed and bailing out early from XkbInitKeyboardDeviceStruct if it hasn't. However, I think this still leaves you with two xkbcomps during the startup in the common configuration. XkbInitKeyboardDeviceStruct will be called first via InitCoreDevices with the default ruleset (base, pc105, us, NULL, NULL). Then the driver will call XkbInitKeyboardDeviceStruct again with a ruleset that is probably different (most likely rules == evdev). So, you're going to get two keymap conversions in most cases, anyway, but at least totally gratuitous conversions can be removed. I'll send that patch after I test it a bit. So the path is XkbInitKeyboardDeviceStruct:xkb/xkbInit.c - XkbDDXNamesFromRules:xkb/ddxLoad.c this is where all the rules parsing happens, skipping that may save time. - XkbDDXLoadKeymapByNames:xkb/ddxLoad.c this is where xkbcomp is called with the Kcstg format. xkbcomp now parses that into an xkm format - XkmReadFile:xkb/xkmread.c here we read in the compiled keymap and basically copy it into the internal structs. Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. right, you'd go from oh, same RMLVO to xkmRead() directly. In theory, you could just memcpy the structs from another device but that's not a task for the faint-hearted. But, why not oh, same RMLVO, do nothing? Oh, that's because you have to do it for each device. I guess then you probably want to keep the xkm file in that case, and only unlink during CloseDownDevices or something. Unfortunately, the xkm file is immediately deleted right now. This really only helps if you have multiple keyboards or you're hotplugging them, though. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Notify DRI when crtc regions change
On Fri, 2008-11-14 at 12:50 -0800, Keith Packard wrote: Drivers that care about crtc positions on the screen to ensure that vblank works correctly need to be notified when crtcs are changed. Provide a hook in the mode setting code that is invoked whenever any configuration is done to the screen. Use this new hook in the DRI code so that DRI clients are notified and receive updated information. I'm not totally convinced that DisableUnusedFunctions is the right place for this to get called, but it's merely overkill. Ack. - ajax 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: X server 1.6 release schedule
On Sat, 2008-11-15 at 15:57 -0200, Paulo César Pereira de Andrade wrote: I volunteered to manage an X server 1.6 release, tentatively scheduled for the end of the year (yes, this year, 2008). This release will include DRI2 and RandR 1.3 support. I'd like to know how much of the new Xinput stuff will be ready in time. I guess it will be required to skip https://bugs.freedesktop.org/show_bug.cgi?id=14730 again. I had that patch working for X Server 1.4 one year ago, and for git master before 1.5 was branched. But did not test it much recently. Anyway, it probably should stay this way, as the patch would be more useful when/if Xorg started using a sdk, with a compromise on backwards compatibility. But at the rate new features are being added, this is unlikely soon :-) Also by only exporting symbols that really should be visible, you get a compromise. Actually, I've been meaning to get this merged for a while now. I'll be happy to take a look at it again. - ajax 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: X server 1.6 release schedule
On Fri, 2008-11-14 at 13:13 -0800, Keith Packard wrote: I volunteered to manage an X server 1.6 release, tentatively scheduled for the end of the year (yes, this year, 2008). This release will include DRI2 and RandR 1.3 support. I'd like to know how much of the new Xinput stuff will be ready in time. Can we define what RANDR 1.3 means? I think we're largely in agreement but I'd like it written down. Here's a proposed schedule of events: Cut a release branch, do a -RC1 release: 11/24 Track remaining work on scheduled features, cherry-picking commits from master. Cut -RC2 12/8 Stop accepting new code, focus on bug fixing. Cut -RC3 12/22 Update documentation, mark known bugs, build packages and ship final bits. 1/5 Sounds like a busy holiday, but since it's not _my_ busy holiday, I don't mind at all. There is still one major bugfix that was only ever applied to 1.5 branch and not master: commit 7822a3d05f935cca3bfa47d15d961596652ecfca Author: Adam Jackson [EMAIL PROTECTED] Date: Tue Jun 17 16:10:51 2008 -0400 XAA: Disable offscreen pixmaps by default. Say Option XaaOffscreenPixmaps to turn them back on. Apropos of bugs #13795 and #15098. Not yet applied to master as this wants a proper solution someday, but then, those bugs aren't closed yet either. Other than that I think the fixes in 1.5.x are a strict subset of what's in master. I'll probably wind down the 1.5 series with one last release when 1.6.0 goes out. - ajax 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: [Patch 01/02] mieq threading prep: Only increment tail (push) when the event data is actually in the queue
Jeremy Huddleston wrote: -unsigned int oldtail = miEventQueue.tail, newtail; +unsigned int oldtail = miEventQueue.tail; All fine, but is there a specific reason to remove newtail? Not that I'd expect this to save more than one or two cycles on any platform... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
Adam Jackson wrote: There is still one major bugfix that was only ever applied to 1.5 branch and not master: commit 7822a3d05f935cca3bfa47d15d961596652ecfca Author: Adam Jackson [EMAIL PROTECTED] Date: Tue Jun 17 16:10:51 2008 -0400 XAA: Disable offscreen pixmaps by default. Say Option XaaOffscreenPixmaps to turn them back on. Apropos of bugs #13795 and #15098. Not yet applied to master as this wants a proper solution someday, but then, those bugs aren't closed yet either. Other than that I think the fixes in 1.5.x are a strict subset of what's in master. I'll probably wind down the 1.5 series with one last release when 1.6.0 goes out. Probably not related to those bugs, but XAA doesn't have a flag to call the sync function for screen to screen copy after every sub blit on hardware that has only 2 directions copy. There was a certain crash with the siliconmotion driver (smi 502) a few seconds after opening youtube, due to the animations on the web page overflowing the engine and locking the entire system. Disabling xaa offscreen pixmaps caused it to do enough computations to not overflow the engine... After changing the xaa code to ensuring the engine is idle before every subsequent screen to screen copy, the problem was corrected. - ajax Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/5] handle extenion for detail timing block
On Mon, 2008-11-17 at 16:33 +0800, [EMAIL PROTECTED] wrote:
From: MaLing[EMAIL PROTECTED]
+struct hdmi {
+ Uchar Support_flags;
+ Uchar Max_TMDS_Clock;
+ Uchar Latency_Present;
+ Uchar Video_Latency;
+ Uchar Audio_Latency;
+ Uchar Interlaced_Video_Latency;
+ Uchar Interlaced_Audio_Latency;
+};
Please, CamelCase or underscore_separated_names, but Not_Both.
@@ -286,11 +381,11 @@ get_std_timing_section(Uchar *c, struct std_timings *r,
static void
get_dt_md_section(Uchar *c, struct edid_version *ver,
- struct detailed_monitor_section *det_mon)
+ struct detailed_monitor_section *det_mon, int det_mon_num)
{
int i;
- for (i=0;iDET_TIMINGS;i++) {
+ for (i=0;idet_mon_num;i++) {
if (ver-version == 1 ver-revision = 1 IS_MONITOR_DESC) {
switch (MONITOR_DESC_TYPE) {
This just walks over the base block, walking from 0 to (det_mon_num-1)
is wrong since det_mon_num will count detailed blocks found in extension
blocks. Should just drop the changes to this function.
- ajax
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: [PATCH 2/5] handle extenion for detail timing block
On Mon, 2008-11-17 at 16:39 +0800, [EMAIL PROTECTED] wrote:
@@ -72,30 +76,6 @@ xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
* Quirks to work around broken EDID data from various monitors.
*/
-typedef enum {
-DDC_QUIRK_NONE = 0,
-/* First detailed mode is bogus, prefer largest mode at 60hz */
-DDC_QUIRK_PREFER_LARGE_60 = 1 0,
-/* 135MHz clock is too high, drop a bit */
-DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 1,
-/* Prefer the largest mode at 75 Hz */
-DDC_QUIRK_PREFER_LARGE_75 = 1 2,
-/* Convert detailed timing's horizontal from units of cm to mm */
-DDC_QUIRK_DETAILED_H_IN_CM = 1 3,
-/* Convert detailed timing's vertical from units of cm to mm */
-DDC_QUIRK_DETAILED_V_IN_CM = 1 4,
-/* Detailed timing descriptors have bogus size values, so just take the
- * maximum size and use that.
- */
-DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 5,
-/* Monitor forgot to set the first detailed is preferred bit. */
-DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 6,
-/* use +hsync +vsync for detailed mode */
-DDC_QUIRK_DETAILED_SYNC_PP = 1 7,
-/* Force single-link DVI bandwidth limit */
-DDC_QUIRK_DVI_SINGLE_LINK = 1 8,
-} ddc_quirk_t;
-
static Bool quirk_prefer_large_60 (int scrnIndex, xf86MonPtr DDC)
{
/* Belinea 10 15 55 */
This hunk should be part of the previous patch, I suspect.
- ajax
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: [PATCH 3/5] handle extenion for detail timing block
On Mon, 2008-11-17 at 16:46 +0800, [EMAIL PROTECTED] wrote:
@@ -2687,14 +2725,9 @@ xf86OutputGetEDIDModes (xf86OutputPtr output)
_X_EXPORT xf86MonPtr
xf86OutputGetEDID (xf86OutputPtr output, I2CBusPtr pDDCBus)
{
-ScrnInfoPtr scrn = output-scrn;
-xf86MonPtr mon;
-mon = xf86DoEEDID(scrn-scrnIndex, pDDCBus, TRUE);
-if (mon)
-xf86DDCApplyQuirks(scrn-scrnIndex, mon);
+return xf86DoEEDID(output-scrn-scrnIndex, pDDCBus, TRUE);
-return mon;
}
static char *_xf86ConnectorNames[] = {
I'm really not sure why you've moved quirk application from something we
do once when we get the EDID block, to something we do every time we
walk the detailed descriptors. What's the motivation for that?
- ajax
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: [PATCH] Notify DRI when crtc regions change
On Tue, 2008-11-18 at 14:08 -0500, Adam Jackson wrote: I'm not totally convinced that DisableUnusedFunctions is the right place for this to get called, but it's merely overkill. Ack. Yeah, agreed, but DisableUnusedFunctions is the one thing which is always called at the end of any crtc modification. Someday we'll clean this stuff up... -- [EMAIL PROTECTED] 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: X server 1.6 release schedule
On Tue, 2008-11-18 at 14:36 -0800, Keith Packard wrote: On Tue, 2008-11-18 at 14:42 -0500, Adam Jackson wrote: On Fri, 2008-11-14 at 13:13 -0800, Keith Packard wrote: I volunteered to manage an X server 1.6 release, tentatively scheduled for the end of the year (yes, this year, 2008). This release will include DRI2 and RandR 1.3 support. I'd like to know how much of the new Xinput stuff will be ready in time. Can we define what RANDR 1.3 means? I think we're largely in agreement but I'd like it written down. I think RandR 1.3 includes: 1. Projective transforms 2. Standard properties 3. Per-CRTC DPMS controls 4. Panning Overscan correction? I don't think this counts as a subset of projective transforms, but I could be wrong. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xmove and xpra are the alternatives to xscreen (followup to What is the status of xscreen? Will its development ever be resumed?)
A year ago, Jason Spiro jasonspiro4 at gmail.com wrote: Hi Ori and xorg list members, Ori, you told me last year about the project you were working on: xscreen, a program similar in functionality to Gnu Screen, only for X applications [1], done for Google Summer of Code. I am interested in running Xscreen: I would like to try using it to prevent my applications from aborting when I kill X (e.g. by accident[2].) I also might like to try using it to share single applications, not entire Xorg displays, between me and others. Ori, gitweb shows that you checked in lots of code to the orib-soc-2006 branch of xorg [3], but that it was not merged into HEAD. Did you manage to finish implementing xscreen? If not, what was finished, what was not, and what would need to be done to get xscreen working? Xorg people: Do you think it's likely that you will resume development of xscreen in the future, either by yourself or by finding more Summer of Code students to work on it? ( I would not volunteer though. ) Or is VNC good enough that it wouldn't be worth it to develop xscreen further? Regards, Jason Spiro [1] http://code.google.com/soc/2006/xorg/appinfo.html?csaid=73A89F18E7770493 [2] Btw, Ctrl+Alt+Backspace is a pet peeve of mine. See my feature request https://bugs.freedesktop.org/show_bug.cgi?id=10507 - Ctrl-Alt-Backspace should request confirmation before killing Xorg. [3] http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=shortlog;h=orib-soc-2006 There are two alternatives to xscreen. - xmove (unmaintained since 1997; see http://wikipedia.org/wiki/xmove for more info on what xmove does) - xpra But xscreen is not a good choice, because it isn't done. I spoke with Ori on MSN Messenger this April. He told me (I have edited his words slightly): I don't think Xscreen will even compile. At the end of the summer I was working on Xscreen, a whole bunch of APIs it was depending on changed: both XCB's API and Xorg internals. And in general, I was inexperienced and clueless at the time: Xscreen still needs major cleanups. There are lots of issues with global resources, etc. that I'm not even sure how to approach now today. It's harder to write a _good_ X proxy than it looks. I'll make an announcement if I ever find time to pick it up again. -Jason ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver 1.5.3: DeliverPropertyEvent() accessing unallocated memory
Matthieu Herrb wrote:
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
Here's a short debugging session that shows the problem (0xfd is the
value used to fill free()'d regions:
Program received signal SIGSEGV, Segmentation fault.
0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
34 pHead = LookupIDByType(pWin-drawable.id, RREventType);
(gdb) p **WindowTable
$1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
0xdfdfdfdf,
nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
origin = {x = -8225, y = -8225}, borderWidth = 57311,
deliverableEvents = 57311, eventMask = 3755991007, background = {
pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
0xdfdfdfdf,
pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
= 1,
saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
forcedBG = 1}
(gdb) bt
#0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
#1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:225
#2 0x1c025d03 in WalkTree (pScreen=0x81310400,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:253
#3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
event=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:62
#4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
at /usr/xenocara/xserver/randr/rrproperty.c:80
#5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
at /usr/xenocara/xserver/randr/rroutput.c:410
#6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
at /usr/xenocara/xserver/dix/resource.c:809
#7 0x1c02515e in FreeAllResources ()
at /usr/xenocara/xserver/dix/resource.c:826
#8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
at /usr/xenocara/xserver/dix/main.c:453
(gdb)
Ideas for fixing that are of course welcome.
I've added an ErrorF() call to FreeClientResources() to show the same
info as the DTrace probe in this function. It confirms that the
rootwindow (in the case of a simle server with no client windows) is
destroyed before the outputs:
FreeClientResources MODE 41 7c0c1f00
FreeClientResources MODE 40 7c0c1e00
FreeClientResources MODE 43 7c0c1a40
FreeClientResources MODE 42 7c0c1b40
FreeClientResources MODE 45 7c0c1d80
FreeClientResources MODE 44 7c0c1b00
FreeClientResources MODE 47 840e9100
FreeClientResources MODE 46 7c0c1ec0
FreeClientResources MODE 49 840e9300
FreeClientResources MODE 48 840e92c0
FreeClientResources MODE 4b 840e94c0
FreeClientResources MODE 4a 840e9140
FreeClientResources MODE 4d 840e9040
FreeClientResources MODE 4c 840e9380
FreeClientResources unknown 4f 840e90c0
FreeClientResources MODE 4e 7c0c1c40
FreeClientResources unknown 51 80e5ad20
FreeClientResources unknown 50 80e5a9e0
FreeClientResources COLORMAP 20 82d64000
FreeClientResources PICTFORMAT 23 7e959000
FreeClientResources PICTFORMAT 24 7e959030
FreeClientResources PICTFORMAT 25 7e959060
FreeClientResources PICTFORMAT 26 7e959090
FreeClientResources PICTFORMAT 27 7e9590c0
FreeClientResources PICTFORMAT 28 7e9590f0
FreeClientResources PICTFORMAT 29 7e959120
FreeClientResources PICTFORMAT 2a 7e959150
FreeClientResources PICTFORMAT 2b 7e959180
FreeClientResources PICTFORMAT 2c 7e9591b0
FreeClientResources PICTFORMAT 2d 7e9591e0
FreeClientResources PICTFORMAT 2e 7e959210
FreeClientResources PICTFORMAT 2f 7e959240
FreeClientResources PICTFORMAT 30 7e959270
FreeClientResources PICTFORMAT 31 7e9592a0
FreeClientResources PICTFORMAT 32 7e9592d0
FreeClientResources
Re: Moving xkbcomp into the server
On Tue, Nov 18, 2008 at 2:21 PM, Peter Hutterer
[EMAIL PROTECTED] wrote:
On Tue, Nov 18, 2008 at 11:08:36AM -0800, Dan Nicholson wrote:
I think it'd be less effort to leave the converter as-is and remove the
need
for calling it, but that's a guess only too.
So, I took a look at this, and it was fairly easy to write an
(untested) patch that checks if RMLVO has been changed and bailing out
early from XkbInitKeyboardDeviceStruct if it hasn't. However, I think
this still leaves you with two xkbcomps during the startup in the
common configuration. XkbInitKeyboardDeviceStruct will be called first
via InitCoreDevices with the default ruleset (base, pc105, us,
NULL, NULL). Then the driver will call XkbInitKeyboardDeviceStruct
again with a ruleset that is probably different (most likely rules ==
evdev). So, you're going to get two keymap conversions in most
cases, anyway, but at least totally gratuitous conversions can be
removed. I'll send that patch after I test it a bit.
As the theory goes, at least under linux we should be able to change the
default ruleset of evdev, etc. anyway, which skips another xkbcomp
invocation.
Right now the defaults are hardcoded via XkbSetRulesDflts into dix/devices.c:
#ifdef XKB
if (!noXkbExtension) {
bzero(names, sizeof(names));
XkbSetRulesDflts(base, pc105, us, NULL, NULL);
XkbInitKeyboardDeviceStruct(pDev, names, keySyms, modMap,
CoreKeyboardBell, CoreKeyboardCtl);
}
else
#endif
The XkbSetRulesDflts isn't strictly necessary, though, since the xkb
code has it's own built-in defaults that it will fall back to if no
new defaults are set:
xkb/xkbInit.c:
#ifndef XKB_DFLT_RULES_FILE
#define XKB_DFLT_RULES_FILE rules
#endif
#ifndef XKB_DFLT_KB_LAYOUT
#define XKB_DFLT_KB_LAYOUT us
#endif
#ifndef XKB_DFLT_KB_MODEL
#define XKB_DFLT_KB_MODEL dflt
#endif
#ifndef XKB_DFLT_KB_VARIANT
#define XKB_DFLT_KB_VARIANT NULL
#endif
#ifndef XKB_DFLT_KB_OPTIONS
#define XKB_DFLT_KB_OPTIONS NULL
#endif
So, it would be fairly easy to use these macros and just set a linux
build time default:
if test $host_os = linux; then
dflt_xkb_rules=evdev
else
dflt_xkb_rules=base
fi
AC_DEFINE_UNQUOTED([XKB_DFLT_RULES_FILE], [$dflt_xkb_rules], [Default
XKB rules file])
And change the XKB_DFLT_KB_MODEL default to pc105. I don't know if
that screws with people trying to use the kbd driver on linux, though
(don't know if we care, either).
But, why not oh, same RMLVO, do nothing? Oh, that's because you have
to do it for each device. I guess then you probably want to keep the
xkm file in that case, and only unlink during CloseDownDevices or
something. Unfortunately, the xkm file is immediately deleted right
now. This really only helps if you have multiple keyboards or you're
hotplugging them, though.
well, since the xkms hardly ever change across server instances finding a way
to buffer them across multiple restarts would fix that problem too. Then you
really only have xkmRead() for each keyboard, no xkbcomp anymore.
Oh, btw:
[EMAIL PROTECTED]:~$ grep Configuring as keyboard /var/log/Xorg.0.log
(II) Power Button (FF): Configuring as keyboard
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) Sleep Button (CM): Configuring as keyboard
(II) ThinkPad Extra Buttons: Configuring as keyboard
(II) Video Bus: Configuring as keyboard
(II) Video Bus: Configuring as keyboard
If I'm not completely wrong, xkbcomp will be called for all of them, so
chances are high that you have a multiple keyboard setup.
Wow, hadn't noticed that, and checking through the evdev source shows
that the keymap will be reconfigured each time. OK, I'll just work on
this first and see if I can get it down to a single xkbcomp for
default configurations.
--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xserver 1.5.3: DeliverPropertyEvent() accessing unallocated memory
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
Here's a short debugging session that shows the problem (0xfd is the
value used to fill free()'d regions:
Program received signal SIGSEGV, Segmentation fault.
0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
34 pHead = LookupIDByType(pWin-drawable.id, RREventType);
(gdb) p **WindowTable
$1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
0xdfdfdfdf,
nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
origin = {x = -8225, y = -8225}, borderWidth = 57311,
deliverableEvents = 57311, eventMask = 3755991007, background = {
pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
0xdfdfdfdf,
pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
= 1,
saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
forcedBG = 1}
(gdb) bt
#0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
#1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:225
#2 0x1c025d03 in WalkTree (pScreen=0x81310400,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:253
#3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
event=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:62
#4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
at /usr/xenocara/xserver/randr/rrproperty.c:80
#5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
at /usr/xenocara/xserver/randr/rroutput.c:410
#6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
at /usr/xenocara/xserver/dix/resource.c:809
#7 0x1c02515e in FreeAllResources ()
at /usr/xenocara/xserver/dix/resource.c:826
#8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
at /usr/xenocara/xserver/dix/main.c:453
(gdb)
Ideas for fixing that are of course welcome.
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: /dev/uinput with X11
On Tue, Nov 18, 2008 at 10:16:05PM +0800, Leandro Galvez wrote: How do I use the X11 with /dev/uinput device which I plan to simulate all the input devices like keyboard, mouse and touchpad? How do I create the xorg.conf for this to properly work? Do I need an entry for each type or can I integrate all the input device types into one single input device entry in xorg.conf? You don't need to do anything. When you create the device, HAL sends the information to the server, which then picks it up and configures it appropriately. So you do the same thing as for a physical device - add your stuff into the fdi file or set up an xorg.conf entry for it. (FYI evdev git master has test/ directory that provides a simple uinput devices for testing. Maybe that's a starting point for you) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Tue, 2008-11-18 at 18:23 -0500, Adam Jackson wrote: Overscan correction? I don't think this counts as a subset of projective transforms, but I could be wrong. No, not a part of projective transforms as it doesn't change the pixel-pixel mapping. It sounds useful; get some code together along with a spec update and we can ship it too. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-evdev 2.0.8
Expect this to be the last evdev 2.0.x release. Julien Cristau (1): Fix TestBit() on 64bit Peter Hutterer (1): evdev 2.0.8 git tag: xf86-input-evdev-2.0.8 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.8.tar.bz2 MD5: 7f9ace5bcca1427b0da40827a74cbc33 xf86-input-evdev-2.0.8.tar.bz2 SHA1: 57a88717a621957d82169b7508ef293214f4b952 xf86-input-evdev-2.0.8.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.8.tar.gz MD5: 766876581c436edd3340cdca16c5aeee xf86-input-evdev-2.0.8.tar.gz SHA1: 039880cf19a5031c364e4bcdd8ac9309f1ee932b xf86-input-evdev-2.0.8.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-evdev 2.1.0
No blockers reported since the last RC, so let's get it out of the way. The new evdev 2.1 is here, and it's sparkly and shiny and whatnot. Note that this version does not grab the event device anymore. If you're updating from evdev 2.0, ensure you have [1] in the server to avoid events being sent to the TTY. Other patches of interest [2-4] are recommended to avoid duplicate events. Consider the evdev 2.0 branch to be discontinued. The shortlog since RC 3: Fernando Carrijo (1): Fix error message Peter Hutterer (2): Store device file's minor/major to avoid duplicate devices. evdev 2.1 git tag: xf86-input-evdev-2.1.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.1.0.tar.bz2 MD5: a6070ead29b2d81b5b386a96df2661b8 xf86-input-evdev-2.1.0.tar.bz2 SHA1: afa5b981e4205fbefe1a21b95fa973f1c6532142 xf86-input-evdev-2.1.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.1.0.tar.gz MD5: a4f3cbb67db5374aa5d0ecb8f18c05e1 xf86-input-evdev-2.1.0.tar.gz SHA1: 9599f6219a278a189d830cda374455f585ce294d xf86-input-evdev-2.1.0.tar.gz Cheers, Peter [1] http://cgit.freedesktop.org/xorg/xserver/commit/?id=d936a4235c9625bd41569cef3452dd086284e0d7 [2] http://cgit.freedesktop.org/xorg/xserver/commit/?id=6c451859552e1fc78f6589617482f9ff96d7ed8a [3] http://cgit.freedesktop.org/xorg/xserver/commit/?id=c264826da96ad1859dd112b17eb8aa9e5278478f [4] http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b56b44addc323a00eb7cd86240cb0dd4275bcf8 pgp0jMc2LijMn.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
Hi,
On Mon, Nov 17, 2008 at 11:25:25AM -0800, Dan Nicholson wrote:
I decided to take a crack at moving xkbcomp into the server so it's
not popen'd whenever a keymap is loaded. For the first crack, I'm
trying to just leave xkbcomp pretty much unchanged except for the
interface. What's causing me the most difficulty is converting to
server API. One snag I've hit is XStringToKeysym. Here's an example
usage in the xkbcomp parser:
int
LookupKeysym(char *str, KeySym * sym_rtrn)
{
[...]
}
Is there an equivalent API in the server to do this conversion?
Is this crazy/am I going about this the wrong way?
Any general suggestions for working on this?
No, yes, and break it out into a convenience library, respectively. I
toyed with creating a libxkbcommon ages ago for exactly this reason, but
never ended up finishing it.
Cheers,
Daniel
signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Moving xkbcomp into the server
Hi, On Tue, Nov 18, 2008 at 11:08:36AM -0800, Dan Nicholson wrote: On Tue, Nov 18, 2008 at 4:28 AM, Peter Hutterer [EMAIL PROTECTED] wrote: Right. So, ideally what would happen is: 1. Skip parsing completely if the rules haven't changed. 2. Go directly from RMLVO-internal structs. Or at least make the intra-conversion states not involve reading/writing/parsing files. right, you'd go from oh, same RMLVO to xkmRead() directly. In theory, you could just memcpy the structs from another device but that's not a task for the faint-hearted. But, why not oh, same RMLVO, do nothing? Oh, that's because you have to do it for each device. I guess then you probably want to keep the xkm file in that case, and only unlink during CloseDownDevices or something. Unfortunately, the xkm file is immediately deleted right now. This really only helps if you have multiple keyboards or you're hotplugging them, though. I'd rather ditch the XKM completely, and go from RMLVO to KcCGST (this part of the conversion isn't hideously painful, though I'm sure the rules parsing could be made faster and more efficient) to XkbDescRec. This basically just means shoving xkbcomp into the server and deleting all the code that deals with XKM: just delivering the XkbDescRec it builds anyway. I haven't profiled this, so I'm likely to be wrong, but my money's on having to create a new file, wait while our fork()ed process writes it out, waiting for it to bail, then reading back and deserialising the very same file into the exact same format, being a reasonable part of the performance problem. That and the actual lexer/etc is crap. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/7] (updated) dix: Add EnterWindow, LeaveWindow, HasPointer auxiliary functions.
These replace the ENTER_LEAVE_SEMAPHORE_* macros. Unused currently.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
The newly added HasOtherPointer() function is needed to provide correct
enter/leave event handling during active grabs.
dix/enterleave.c | 50 ++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/dix/enterleave.c b/dix/enterleave.c
index 11929c6..57d1f1e 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -34,6 +34,56 @@
#include enterleave.h
/**
+ * Return TRUE if @win has a pointer within its boundaries, excluding child
+ * window.
+ */
+static BOOL
+HasPointer(WindowPtr win)
+{
+int i;
+
+for (i = 0; i sizeof(win-enterleave); i++)
+if (win-enterleave[i])
+return TRUE;
+
+return FALSE;
+}
+
+static BOOL
+HasOtherPointer(WindowPtr win, DeviceIntPtr dev)
+{
+int i;
+
+for (i = 0; i sizeof(win-enterleave); i++)
+if (win-enterleave[i]
+!(i == dev-id/8 win-enterleave[i] == (1 (dev-id % 8
+{
+return TRUE;
+}
+
+return FALSE;
+}
+
+/**
+ * Set the presence flag for @dev to mark that it is now in @win.
+ */
+static void
+EnterWindow(DeviceIntPtr dev, WindowPtr win, int mode)
+{
+win-enterleave[dev-id/8] |= (1 (dev-id % 8));
+}
+
+/**
+ * Unset the presence flag for @dev to mark that it is not in @win anymore.
+ */
+static void
+LeaveWindow(DeviceIntPtr dev, WindowPtr win, int mode)
+{
+win-enterleave[dev-id/8] = ~(1 (dev-id % 8));
+}
+
+
+/**
* @return The window that is the first ancestor of both a and b.
*/
WindowPtr
--
1.6.0.3
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 6/7] (updated) dix: updated enter/leave core event model.
As proposed by Owen Taylor [1], the enter-leave event model needs to adjust
the events sent to each window depending on the presence of pointers in a
window, or in a subwindow.
The new model can be summarised as:
- if the pointer moves into or out of a window that has a pointer in a child
window, the events are modified to appear as if the pointer was moved out of
or into this child window.
- if the pointer moves into or out of a window that has a pointer in a parent
window, the events are modified to appear as if the pointer was moved out of
or into this parent window.
Note that this model requires CoreEnterLeaveEvent and DeviceEnterLeaveEvent to
be split and treated separately.
[1] http://lists.freedesktop.org/archives/xorg/2008-August/037606.html
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
This is the updated model that now caters for enter/leave events during active
grabs correctly (according to my testing). Since the pointer may enter a
window while a grab is active, we need to check only for _other_ pointers in
the target window before sending the event. Otherwise, UngrabNotify events
may not get through.
dix/devices.c|4 +-
dix/enterleave.c | 268 +-
dix/enterleave.h |4 +
3 files changed, 274 insertions(+), 2 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index 2ec9284..a69 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -86,6 +86,7 @@ SOFTWARE.
#include exevents.h
#include listdev.h /* for CopySwapXXXClass */
#include xiproperty.h
+#include enterleave.h /* for EnterWindow() */
#include xserver-properties.h
/** @file
@@ -284,7 +285,8 @@ EnableDevice(DeviceIntPtr dev)
if (dev-spriteInfo-spriteOwner)
{
InitializeSprite(dev, WindowTable[0]);
-ENTER_LEAVE_SEMAPHORE_SET(WindowTable[0], dev);
+ /* mode doesn't matter */
+EnterWindow(dev, WindowTable[0], NotifyAncestor);
}
else if ((other = NextFreePointerDevice()) == NULL)
{
diff --git a/dix/enterleave.c b/dix/enterleave.c
index 0f3b12f..8176f96 100644
--- a/dix/enterleave.c
+++ b/dix/enterleave.c
@@ -33,6 +33,80 @@
#include exglobals.h
#include enterleave.h
+/* @file This file describes the model for sending core enter/leave events in
+ * the case of multiple pointers.
+ * Since we can't send more than one Enter or Leave event per window
+ * to a core client without confusing it, this is a rather complicated
+ * approach.
+ *
+ * For a full description of the model from a window's perspective, see
+ * http://lists.freedesktop.org/archives/xorg/2008-August/037606.html
+ *
+ *
+ * EnterNotify(Virtual, B) means EnterNotify Event, detail Virtual, child = B.
+ *
+ * Pointer moves from A to B, nonlinear (CoreEnterLeaveNonLinear):
+ * 1. a. if A has another pointer, goto 2.
+ *b. otherwise, if A has a child with a pointer in it,
+ * LeaveNotify(Inferior) to A
+ * LeaveNotify(Virtual) between A and child(A)
+ *
+ * 2. Find common ancestor X between A and B.
+ * 3. Find closest pointer window P between A and X.
+ *a. if P exists
+ * LeaveNotify(Ancestor) to A
+ * LeaveNotify(Virtual) between A and P
+ *b. otherwise, if P does not exist,
+ * LeaveNotify(NonLinear) to A
+ * LeaveNotify(NonLinearVirtual) between A and X.
+ *
+ * 4. If X does not have a pointer, EnterNotify(NonLinearVirtual, B) to X.
+ * 5. Find closest pointer window P between X and B.
+ *a. if P exists, EnterNotify(NonLinearVirtual) between X and P
+ *b. otherwise, EnterNotify(NonLinearVirtual) between X and B
+ *
+ * 5. a. if B has another pointer in it, finish.
+ *b. otherwise, if B has a child with a pointer in it
+ * LeaveNotify(Virtual) between child(B) and B.
+ * EnterNotify(Inferior) to B.
+ *c. otherwise, EnterNotify(NonLinear) to B.
+ *
+ * --
+ *
+ * Pointer moves from A to B, A is a parent of B (CoreEnterLeaveToDescendant):
+ * 1. a. If A has another pointer, goto 2.
+ *b. Otherwise, LeaveNotify(Inferior) to A.
+ *
+ * 2. Find highest window X that has a pointer child that is not a child of B.
+ *a. if X exists, EnterNotify(Virtual, B) between A and X,
+ * EnterNotify(Virtual, B) to X (if X has no pointer).
+ *b. otherwise, EnterNotify(Virtual, B) between A and B.
+ *
+ * 3. a. if B has another pointer, finish
+ *b. otherwise, if B has a child with a pointer in it,
+ * LeaveNotify(Virtual, child(B)) between child(B) and B.
+ * EnterNotify(Inferior, child(B)) to B.
+ *c. otherwise, EnterNotify(Ancestor) to B.
+ *
+ * --
+ *
+ * Pointer moves from A to B, A is a child of B (CoreEnterLeaveToAncestor):
+ * 1. a. If A has another pointer, goto 2.
+ *b.
Current tinderbox regression (xf86-video-geode)
http://tinderbox.x.org/builds/2008-11-18-0033/ http://tinderbox.x.org/builds/2008-11-18-0033/logs/xf86-video-geode/#build lx_driver.c: In function 'LXUnmapMem': lx_driver.c:621: error: 'pGeode' undeclared (first use in this function) -- Chris Ball [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X server 1.6 release schedule
On Sat, 2008-11-15 at 15:57 -0200, Paulo César Pereira de Andrade wrote:
I volunteered to manage an X server 1.6 release, tentatively scheduled
for the end of the year (yes, this year, 2008). This release will
include DRI2 and RandR 1.3 support. I'd like to know how much of the
new
Xinput stuff will be ready in time.
I guess it will be required to skip
https://bugs.freedesktop.org/show_bug.cgi?id=14730 again.
I had that patch working for X Server 1.4 one year ago, and for
git master before 1.5 was branched. But did not test it much
recently. Anyway, it probably should stay this way, as the patch would
be more useful when/if Xorg started using a sdk, with a compromise on
backwards compatibility. But at the rate new features are being added,
this is unlikely soon :-) Also by only exporting symbols that really
should be visible, you get a compromise.
Actually, I've been meaning to get this merged for a while now. I'll be
happy to take a look at it again.
I think the patches should still apply (besides some patches for
mfb and glx/*.c). But I can review it again.
Actually, I built a framework to work on this. I added the xedit
ctags interface just for this :-), and wrote a perl script that will
use objdump to list all external symbols provided/required by modules
and X Server, and print where the symbols are found.
The logic for finding where a symbol is defined is very simple:
o Check X Server and libraries linked to it.
o Check all other modules in the module path, the script can handle
multiple module path, but it cannot ensure the driver is actually
loading a module.
It will also print a warning about multiple definitions.
I think I got all patches required for modules already commited,
but not for libraries (to define as weak some symbols also defined
in the X Server).
Points where special attention is required:
o Usage of LoaderSymbol() or dlsym. For this I just grep'ed everything,
and resolved by hand the missing symbols. Check hw/xfree86/i2c/*.h
for awesome samples, where it will cast to a function and call the
value returned by LoaderSymbol(). The ati multimedia drivers had
some very similar usage, but that should have been fixed now, only
missing feature there would be to be able to load the different
multimedia drivers, as they all provide symbols with the same name,
instead, it should provide a vector of driver callbacks. But see
xorg/driver/xf86-video-ati/src/theatre.h for a sample of how to
correct that usage of LoaderSymbol without breaking abi.
o Symbols also defined in libraries. Best example is libXfont. if
the X Server is plainly compiled with -fvisibility=hidden, it
will not say there are missing symbols and use the stubs in libXfont,
and the script will not even show the duplicated symbols (gcc can
make some very aggressive optimizations when a symbol is not
accessible from other shared objects, and just inline the hidden
function).
o Some symbols are a pain to find. My idea is to make some extra
patches just to make finding symbols (with your preferred text
editor :-) easier. The most important one is change things like:
-%-
#define NAME(function)prefix ## name
type NAME(foo) { bar }
-%-
to:
-%-
#define BODY bar;
type prefix_foo { BODY }
-%-
This also to handle the other common case of symbols hard to find:
-%-
type
#ifdef FOO
foo_name
#else
bar_name
#endif
(arguments) { baz }
I don't remember if there are any files generated on the fly now,
after the removal of mfb and xfxbpp
-%-
o There are drivers that access private symbols, that is, symbols
not in /usr/include/xorg/*.h.
I don't have a tool to generate information about these, but once
I posted a list of symbols used by modules that are not in the
sdk, and symbols in the sdk that are not used by any module (the
script tells about symbols exported but not used by any module).
But when/if making symbols easier to find, generating such list
even by hand would not take much time.
In the worst case, the framework is still good to find things
like macros being compiled as a call to a function (due to not
including the header with macro definition), or just plain code
that calls functions no longer available.
Also, besides the temptation, I did not ansify the X Server
code to attempt to reduce patches size (it is still huge, besides
having one patch addressing a different problem).
Another detail is that it really needs some major review to
decide what really needs to be in the sdk, because to have it
properly implemented, everything in /usr/include/xorg/*.h should
be made available, and I think like only half of those symbols are
tagged _X_EXPORT.
Yet another detail, it may be a good idea to also use gcc's
visibility pragmas before inclusion of headers of external libraries.
My original patches to util/macros was to have a @@HIDDEN_SYMBOLS@@
and @@PUBLIC_SYMBOLS@@, but probably it is
Re: [Patch 01/02] mieq threading prep: Only increment tail (push) when the event data is actually in the queue
On Nov 18, 2008, at 11:54, Simon Thum wrote: Jeremy Huddleston wrote: -unsigned int oldtail = miEventQueue.tail, newtail; +unsigned int oldtail = miEventQueue.tail; All fine, but is there a specific reason to remove newtail? Not that I'd expect this to save more than one or two cycles on any platform... I just thought it was adding to namespace polution, TBH... no real reason... and with any level of optimization, you'll get back those two cycles. I can revert that part if you really care. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: /dev/uinput with X11
Thank you very much guys for your replies. - Original Message - From: Peter Hutterer [EMAIL PROTECTED] To: Leandro Galvez [EMAIL PROTECTED] Cc: xorg@lists.freedesktop.org Sent: Wednesday, November 19, 2008 7:56 AM Subject: Re: /dev/uinput with X11 On Tue, Nov 18, 2008 at 10:16:05PM +0800, Leandro Galvez wrote: How do I use the X11 with /dev/uinput device which I plan to simulate all the input devices like keyboard, mouse and touchpad? How do I create the xorg.conf for this to properly work? Do I need an entry for each type or can I integrate all the input device types into one single input device entry in xorg.conf? You don't need to do anything. When you create the device, HAL sends the information to the server, which then picks it up and configures it appropriately. So you do the same thing as for a physical device - add your stuff into the fdi file or set up an xorg.conf entry for it. (FYI evdev git master has test/ directory that provides a simple uinput devices for testing. Maybe that's a starting point for you) Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dual Head DVI on Q965/Q963 Express Chipset Family
On Tue, Nov 18, 2008 at 02:07:51PM +0100, Hannes Mezger wrote: hi, i tried to get my kubuntu (newest version) running in dual head mode. i have a fujitsu siemens celsius w350 workstation with the Q965/Q963 chipset on board. additional i have a add2 card which gives me 2 dvi ports. the drivers installed are the newest from kubuntu (2:2.4.1), but i just can't get my xserver so recognize the two dvi outputs. xrandr tells me about one vga connector (on board) and one tmds connector, but never sees the second dvi connector. would be great if anybody knew a solution for this.. cheers, hannes begin:vcard fn:Hannes Mezger n:Mezger;Hannes org:ascolab GmbH adr:;;Am Weichselgarten 7;Erlangen;;91058;Germany email;internet:[EMAIL PROTECTED] tel;work:+49 9131 691 124 tel;fax:+49 9131 691 128 tel;cell:+49 171 8115522 note;quoted-printable:Handelsregister/Commercial Register: Amtsgericht F=C3=BCrth HRB 9360=0D=0A= Gesch=C3=A4ftsf=C3=BChrer/Managing Directors: Gerhard Gappmeier, Matthias= Damm, Uwe Steinkrau=C3=9F url:www.ascolab.com version:2.1 end:vcard ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I have managed this with the latest everything. Initially I had two blank screens. In xorg.conf, intel device section, I had to set the ForceSDVODetect option to see TMDS-2 I had to comment out Monitor-LVDS option, even though it was a null monitor, to see TMDS-1. I had Monitor-TMDS-1 and Monitor-TMDS-2 set. I did find, (and commented in another posting), that the intel driver incorrectly uses a reserved bit to determine if the TMDS-2 monitor was initially connected. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
