Re: Question about multiple X11 and screencaptures
On Wednesday 29 September 2010 12:27:08 Marc Cambier wrote: > Hello, > > I have a command 'cmd', which takes a screencapture. > > I have two X running : > - Display :0 on VT2 > - Display :1 on VT3 > > I go to VT2 : CTRL+ALT+F2 > I launch cmd : I have screenshot of the display :0, it's OK > > I go to VT3 : CTRL+ALT+F3 > I launch cmd : I have screenshot of the display :1, it's OK > > But, I have an X program running on display :1, which takes screencaptures > while I'm using display :0. > > And that doesn't work, for example : > I go to VT3 : CTRL+ALT+F3 > I launch "sleep 20 && cmd" > During the sleep, I go to VT2 : CTRL+ALT+F2 > I wait 20 seconds... Screenshot is done, but the result image is totally > black. > > So, I suppose something makes the display :1 "blank" when I'm on display :0 > ; > I searched around the web, but didn't find any explication... > > Pleaz, > Could someone explain me this behaviour ? You have one set of hardware to draw on. Each time you switch VT the hardware is given to the VT. You can only get pixels from the hardware for the VT that is active. The inactive VT's cannot return pixels. > Is there a way to get rid of this problem ? > > I can provide you more informations if you ask... > > Thanks. > M. > Barry ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch: libXt-1.0.8 fix possible array overflow
On Wednesday 22 September 2010 08:18:21 walter harms wrote: > hi List, > the code checks the upperlimit to 10 while the upperlimit is actualy 9. You could use "(sizeof( par )/sizeof( String ))-1" to make the code robust aginst a change to the size of par. Barry > > re, > wh > > > --- libXt-1.0.8/src/Error.c.org 2010-09-21 23:23:00.0 +0200 > +++ libXt-1.0.8/src/Error.c 2010-09-21 23:24:03.0 +0200 > @@ -257,7 +257,7 @@ > */ > Cardinal i = *num_params; > String par[10]; > - if (i > 10) i = 10; > + if (i > 9) i = 9; > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero( &par[i], (10-i) * sizeof(String) ); > (void) fprintf (stderr, "%s%s", > @@ -292,7 +292,7 @@ > */ > Cardinal i = *num_params; > String par[10]; > - if (i > 10) i = 10; > + if (i > 9) i = 9; > (void) memmove((char*)par, (char*)params, i * sizeof(String) ); > bzero( &par[i], (10-i) * sizeof(String) ); > if (i != *num_params) > ___ > xorg@lists.freedesktop.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg > Your subscription address: barry.sc...@onelan.co.uk > > ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X regression
On Sunday 15 August 2010 04:26:29 Joel Feiner wrote: > On Wed, Aug 11, 2010 at 2:56 PM, Frans de Boer wrote: ... > >> > > I tried that before but: > > 1) It does not preserve the settings between sessions. > > > This is annoying, but it's a fixable bug. Is this problem being worked on? OR are you just guessing it could be fixed? I had no luck getting a reply on this issue on the KDE list. I have to reset my screen settings every time I log in, I'd love this annoyance to get fixed. I might even contribute a patch if someone in the know would point me in the right direction. Barry ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Video overlay - Window updating
On 11/03/10 20:50, Aaron Plattner wrote: On Mon, Mar 08, 2010 at 04:41:46AM -0800, Iban Rodriguez wrote: Good Morning, I have a question about video overlay and window repainting. I have a project in which I need to show a video on a non-rect part of an application window. After some attempts I decided to use play the video on one window (window 1) and over it put the application window (window 2) where the zone I want the video to show is painted using the color key of the video overlay. With this configuration the video should be shown as if it were embedded in window 2. However, it works only in some situations, which I describe bellow: 1.- If window 1 (video) is completely covered by window 2, the video doesn't show. 2.- If window 1 (video) is not completely covered by window 2 (app) by the left, the video is only show on the part that is not covered. 3.- If window 1 (video) is not completely covered by window 2 (app) by the bottom, the video is only show on the part that is not covered. 4.- If window 1 (video) is not completely covered by window 2 (app) by the bottom and by the left simultaneously, the video is shown on the parts not covered and also on the parts of window 2 (app) which are painted using the color key of the video overlay. For my project, I need to reproduce the behaviour of case 4 in the situation of case 1 but I don't know how to do it. I have tried it with and without a window manager with the same result. I don't know very much about the X server but the problem seems to be that when it needs to update a window, it repaints the minimum rectangle which cover all pixels that need to be updated so it only shows the video in case 4 where the minimum rectangle is the entire window 1 (because of the parts not covered). So my question is, is there a solution for this problem? Can I tell the X server that some windows must be always completely repainted? Is there any other way for managing the video overlay that avoids this problem? The problem is that this is not a valid use of the overlay. Among other things, you can't assume that the driver really uses a hardware overlay or just fakes it. I suspect what's happening here is that the server is clipping the rendering against the occluding window, and simply skips it for the parts that it thinks are not visible. The X server doesn't know that the hardware would let the video show through into parts of the occluding window. If you want to overlay stuff on top of the video, you'll need to either render it into the original video stream before sending it to Xv or use something that explicitly supports sub-pictures, like VDPAU or XvMC. Or use SHAPE extension to allow the video to show through. Or use compositing if you need to alpha blend on top of the video. Barry ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Getting monitor resolutions when xorg isn't running
On 19/02/10 15:47, David Sveningsson wrote: > On 2010-02-19 16:27, John Tapsell wrote: > >> On 19 February 2010 14:53, David Sveningsson wrote: >> >>> Hi, is it possible to get a list of supported resolutions for a monitor, >>> similar to using xrandr, but even if xorg hasn't been started? >>> >> sudo apt-get install xresprobe >> sudo ddcprobe | grep ^mode: >> > Thanks, good enough. I had to build it from source since I don't run a > debian-based distribution. > > But does xresprobe deal with multiple monitors? > We used to use a program like ddcprobe but hit problems on some hardware because it depended on calling video bios functions to get the DDC. Not all video bios supported what was needed. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Re-mapping the middlemouse paste functionality
On 29/01/10 15:58, Adrian Sud wrote: > Hi, > > I am trying to reconfigure the middle mouse button paste buffer command to > another one of the 7 available buttons on my mouse, but leave the 2nd mouse > button reporting itself as a 2nd mouse button. > > Any googling and browsing of FAQs finds ways to disable the 2nd mouse button > entirely, or map the 2nd mouse button to another button (causing all other > functions tied to the 2nd mouse button to move to that other button as > well). Am I to assume that this is not a configurable thing? > > This may be the wrong place to ask; I am assuming X controls this > middle-click paste buffer access because X is historically the controller of > pointer devices. > The apps control the behaviour not X11. The apps place the data into one of X's clipboards and paste from it when you click the button. > If it is not configurable yet, but is part of X11, let me know and I will > try to find where in the source the paste-buffer access is, and see if I can > modify it to add configurability. > I think you need to find out how to change the apps you use to use another button. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems while writing a Composite Manager with Damage, Render, XFixes and Composite
Arnaud Fontaine wrote: >>>>>> Barry Scott writes: >>>>>> > > Hi, > > > There are cases when you get notify about damage in a drawable > > that has gone by the time you deal with the damage. > > > Read the Compiz sources to see how it deals this these problems, > > thats what we ended up doing. > > Thanks for your reply. Well, once a DestroyNotify event has been > received, I guess I can assume that the Damage object has been freed, > no? > > Sorry I do not have the time at the moment to look at what we did. But as I said we learned a huge amount from reading Compiz source. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problems while writing a Composite Manager with Damage, Render, XFixes and Composite
Arnaud Fontaine wrote: > Hello, > > Any ideas or opinions? > There are cases when you get notify about damage in a drawable that has gone by the time you deal with the damage. Read the Compiz sources to see how it deals this these problems, thats what we ended up doing. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg resolution with VGA Switch
Aaron Plattner wrote: > On Wed, May 27, 2009 at 07:49:18AM -0700, Aurélien PROVIN wrote: > >> Hi, >> >> I bought a VGA switch to switch some devices on one monitor. >> But resolution of my X session is limited to 1024x768 instead of 1920x1200. >> If I hotplug the switch when the X session is started in 1920x1200, it works. >> > > It sounds like the switch is preventing the hardware from reading the > EDID from the monitor. Check /var/log/Xorg.0.log for warnings to that > effect. > This is very likely. We had to buy very carefully to get a KVM that switched DDC signalling. Most don't bother. Check the specs of your KVM. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.99.903
Carl Worth wrote: > On Thu, 2009-04-16 at 17:56 +0100, Barry Scott wrote: > >> The code you have to prevent tearing will only work without compositing. >> > > Yes, I just verified that if I simply start xcompmgr then I get tearing > once again. > > >> What is needed is a change to the compositing app to avoid the tearing. >> Which I think you might have exposed the hooks to with the sync to scan line >> stuff, so long as that is independent of XV. >> > > Actually, I don't think there's anything exposed yet here that the > application can get at. So we'll need to think a bit about how to get > arbitrary applications to ask for and get tear-free behavior. > > But yes, the scanline-based waiting will be very useful, so we just need > to find a good way to let applications get at this. > > The other feature you have that we might used to solve this problem is the "swap buffers" stuff. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.99.903
Carl Worth wrote: > On Thu, 2009-04-16 at 12:34 +0100, Jonathan Miles wrote: > >> Okay, understood... that is strange. I am using Compiz (0.8.2 + whatever >> Ubuntu patches it with). >> >> I'm going to pull the latest git trees later and start looking into this >> in more detail. >> > > Thanks for your willingness to help, Jon. > > I don't know exactly how compiz interacts with xv, but you certainly > might start by trying without compiz running to see if the tearing > behavior changes, (my xv tests were without compiz). > The code you have to prevent tearing will only work without compositing. What is needed is a change to the compositing app to avoid the tearing. Which I think you might have exposed the hooks to with the sync to scan line stuff, so long as that is independent of XV. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Removing shadows underneath windows when using xcompmgr
Daniel Stone wrote: > > > xcompmgr is ... not even remotely performant. I'd suggest looking at > another compositing manager. > > We use xompmgr and I'm wondering what is wrong with the xcompmgr performance wise? Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: No video overlay on Intel X4500HD
Keith Packard wrote: > On Wed, 2009-01-14 at 19:35 +, Daniel Gultsch wrote: > >> Hi Guys, >> >> My major problem is that i dont have the "Intel(R) Video Overlay" but >> only the "Intel(R) Textured Video" - as reported by xvinfo | grep -i >> adaptor. This causes tearing and i really need to watch movies :-) >> > > The textured adapter causes tearing because it doesn't synchronize the > screen update to the vblank. Synchronizing this operation involves > either: > A. queuing a command to stop the graphics engine until the vblank > interval and then queuing the rendering commands right after > that. > B. waiting for the vblank interval to occur and then quickly > queueing suitable rendering commands to the graphics engine > > Or change the client to wait for VBLANK before calling XPutImage. (Only works if the movie player is the only client waiting on VBLANK because of trade offs in the Intel DRM code). Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
This memory leak has been fixed in server 1.5. We reduced the problem to a simple X program. It create two windows that overlap and then calls XCopyArea on the lower window specifying an area of the window that is covered by the upper window. This leaks one region for every copy. If anyone knows where I could look for the fix I could back port to server 1.3. Otherwise we can live with this until we update to server 1.6 later in the year. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
Barry Scott wrote: > I have found the leak. > > At line 202 in miext/cw/cw_ops.c we have: > Sorry this is not the leak. (I followed the wrong caller of miRegionCreate). The leak is coming from this call sequence: #0 miRegionCreate (rect=0x0, size=0) at miregion.c:339 #1 0x0812ed4b in miRectsToRegion (nrects=1, prect=0x9622268, ctype=6) at miregion.c:1674 #2 0x081432ba in ProcShapeRectangles (client=0x962cdb0) at shape.c:358 #3 0x08150c3e in XaceCatchExtProc (client=0x962cdb0) at xace.c:299 #4 0x0808887a in Dispatch () at dispatch.c:457 #5 0x080705aa in main (argc=14, argv=0xbfb27904, envp=0x20108) at main.c:451 In frame 2 ProcShapeRectangles creates the region and stores it in pWin->optional->boundingShape at line 364 via the dstRgn point arg to RegionOperate() 363 case ShapeBounding: 364 destRgn = &pWin->optional->boundingShape; Who is responsible for freeing up that region? The X client? Am I right in thinking that I'm looking at a bug in a client causing this leak? Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
Beso wrote: > 2008/12/23 Barry Scott : > >> I have found the leak. >> >> > isn't it simpler to update the xorg-server version?! 1.3 one is rather > old and probably > I'm working on an embedded system which makes it a big problem to update the Xorg server. > a memory leak bug would have been already discovered and fixed by now. > Also the bug appears to be in the source of 1.6 latest beta. It is very hard to get the right set of conditions to cause this leak. We have been shipping systems with this bug in them for months. On 1000's of systems only 3 have been configured by users to provoke this bug. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
I have found the leak. At line 202 in miext/cw/cw_ops.c we have: (*pBackingGC->ops->CopyArea)(pBackingSrc, pBackingDst, pBackingGC, srcx, srcy, w, h, dstx, dsty); The RegionRec that is returned is lost. Here is the stack trace of the allocation: Breakpoint 1, 0x005cf941 in fbDoCopy (pSrcDrawable=0x9423608, pDstDrawable=0x9423608, pGC=0x9423820, xIn=2, yIn=0, widthSrc=30, heightSrc=40, xOut=0, yOut=0, copyProc=0x5f64a0 , bitPlane=0, closure=0x0) at fbcopy.c:598 warning: Source file is more recent than executable. 598 prgnExposed = miHandleExposures(pSrcDrawable, pDstDrawable, pGC, (gdb) bt #0 0x005cf941 in fbDoCopy (pSrcDrawable=0x9423608, pDstDrawable=0x9423608, pGC=0x9423820, xIn=2, yIn=0, widthSrc=30, heightSrc=40, xOut=0, yOut=0, copyProc=0x5f64a0 , bitPlane=0, closure=0x0) at fbcopy.c:598 #1 0x005f649c in exaCopyArea (pSrcDrawable=0x9423608, pDstDrawable=0x9423608, pGC=0x9423820, srcx=2, srcy=0, width=30, height=40, dstx=0, dsty=0) at exa_accel.c:479 #2 0x0817751a in cwCopyArea (pSrc=0x9423608, pDst=0x9423608, pGC=0x9423820, srcx=2, srcy=0, w=30, h=40, dstx=0, dsty=0) at cw_ops.c:202 #3 0x08173515 in damageCopyArea (pSrc=0x9423608, pDst=0x9423608, pGC=0x9423820, srcx=2, srcy=0, width=30, height=40, dstx=0, dsty=0) at damage.c:830 #4 0x08086a0a in ProcCopyArea (client=0x94222f0) at dispatch.c:1745 #5 0x08150ca1 in XaceCatchDispatchProc (client=0x94222f0) at xace.c:281 #6 0x0808887a in Dispatch () at dispatch.c:457 #7 0x080705aa in main (argc=14, argv=0xbffcc5a4, envp=Cannot access memory at address 0x61 ) at main.c:451 Is the fix as simple as calling miRegionDestory on the returned RegionPtr from (CopyArea)? Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Memory leak in fedora 8 xorg server 1.3
I'm tracking down a memory leak in xorg server 1.3. With some work loads we see a reproducible memory leak in the xorg server. I have got as far as finding that miRegionCreate is being called 46000 times in 5m and the memory it allocates is not being freed. There are 17000 blocks leaked from miRectAlloc as well. Is this a known problem that may be fixed in later code? I'm going to keep in digging deeper into the code to see what I can find out. I'm using mtrace in glibc to find out what is going on and I have been patching out Xalloc to avoid everything being reported as allocated in utils.c. As an aside there are some odd bits of code that I'd like to understand: Why does Xalloc need to check for negative size? It casts the unsigned long size of long and test for < 0. In miregion.c xfreeData macro: Why do a test on the size? Doesn't this lead to a leak of a malloc'ed block of memory? #define xfreeData(reg) if ((reg)->data && (reg)->data->size) xfree((reg)->data) Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
Keith Packard wrote: > On Tue, 2008-09-30 at 17:28 +0100, Barry Scott wrote: > > >> For example mozilla (mozembed). The -nocursor patch avoids the need to >> modify >> any app code at all to remove the unwanted cursors. >> > > Have you tried the XFixes HideCursor request yet? That disables the > cursor on a specific screen. > > I wrote a small program that does: XFixesHideCursor( dpy, DefaultRootWindow( dpy ) ); and that does not do what my -nocursor patch does. I still see the cursor over an applications window. Are you expecting that I have to hunt down every windows on the screen and call hide on it? Also When I call: XFixesShowCursor( dpy, DefaultRootWindow( dpy ) ); I get: xfixes example XFixesQueryExtension => 1 event_base: 113 error_base: 180 XFixesQueryVersion => 1 major_version: 4 minor_version: 0 XFixesShowCursor X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 153 (XFIXES) Minor opcode of failed request: 30 () Serial number of failed request: 9 Current serial number in output stream: 11 Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
Daniel Stone wrote: > On Mon, Sep 29, 2008 at 11:08:04PM +0200, Olivier Guerrier wrote: > > > * People running consumer/embedded systems who can't trust their > apps not to try to change the cursors want to silently drop all > cursor rendering. -> patch required if deemed useful > > We build digital signage players that play movies, html pages, images and text. These players have no mouse or keyboard and the cursor is a visual wart. > Can you not just ship a null cursor theme or something if your apps > insist on setting a cursor? > In our product we embed apps that it is far to painful to modify to turn off the cursor. For example mozilla (mozembed). The -nocursor patch avoids the need to modify any app code at all to remove the unwanted cursors. We are willing to work up a patch if you are willing to accept it. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Make -nocursor a runtime option to and remove the compile time NULL_ROOT_CURSOR
David Greaves wrote:
> (resend - didn't realise xorg was subscribe only)
>
> Hi Keith
>
> After irc discussions I sent this patch in via daniel last december but I
> guess
> it got dropped.
>
> You seem to be an active committer to xorg/xserver so could you commit this
> for
> me or let me know what needs changing.
>
> It is against xorg/xserver git from about an hour ago.
>
>
Am I right in thinking this only disables the cursor over the root
window and not over the
whole screen?
I'd suggest that you name the option --norootcursor not -nocursor if
that is the case.
We would love to have a -nocursor that got ride of the cursor from the
screen
added to Xorg.
We have a patch to do this that we use.
Barry
> Thanks.
>
> David
>
> ===
>
> Make -nocursor a runtime option to and remove the compile time
> NULL_ROOT_CURSOR
>
> This is for use on a picture frame but I guess would be useful on touch
> screens
> and in other situations too.
>
> Signed-off-by: David Greaves <[EMAIL PROTECTED]>
>
> ---
> configure.ac|7 --
> dix/cursor.c| 55 ++
> dix/globals.c |1 +
> doc/Xserver.man.pre |4 +++
> include/dix-config.h.in |3 --
> include/opaque.h|1 +
> os/utils.c |5
> 7 files changed, 37 insertions(+), 39 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 60cdc14..88a2c01 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -492,9 +492,6 @@ AC_ARG_ENABLE(install-libxf86config,
> AC_ARG_ENABLE(builtin-fonts, AS_HELP_STRING([--enable-builtin-fonts], [Use
> only built-in fonts (default: yes)]),
> [BUILTIN_FONTS=$enableval],
> [BUILTIN_FONTS=yes])
> -AC_ARG_ENABLE(null-root-cursor, AS_HELP_STRING([--enable-null-root-cursor],
> [Use an empty root cursor (default: use core cursor)]),
> - [NULL_ROOT_CURSOR=$enableval],
> - [NULL_ROOT_CURSOR=no])
>
> dnl GLX build options
> AC_ARG_WITH(mesa-source, AS_HELP_STRING([--with-mesa-source=MESA_SOURCE],
> [Path to Mesa source tree]),
> @@ -981,10 +978,6 @@ AC_CHECK_FUNC(strncasecmp, [],
> AC_DEFINE([NEED_STRNCASECMP], 1,
> AC_CHECK_FUNC(strcasestr, [], AC_DEFINE([NEED_STRCASESTR], 1,
> [Do not have 'strcasestr'.]))
>
> -if test "x$NULL_ROOT_CURSOR" = xyes; then
> -AC_DEFINE(NULL_ROOT_CURSOR, 1, [Use an empty root cursor])
> -fi
> -
> PKG_CHECK_MODULES([XDMCP], [xdmcp], [have_libxdmcp="yes"],
> [have_libxdmcp="no"])
> if test "x$have_libxdmcp" = xyes; then
> AC_CHECK_LIB(Xdmcp, XdmcpWrap, [have_xdmcpwrap="yes"],
> [have_xdmcpwrap="no"],
> [$XDMCP_LIBS])
> diff --git a/dix/cursor.c b/dix/cursor.c
> index 81540fd..38224cf 100644
> --- a/dix/cursor.c
> +++ b/dix/cursor.c
> @@ -519,39 +519,36 @@ CursorPtr
> CreateRootCursor(char *unused1, unsigned int unused2)
> {
> CursorPtrcurs;
> -#ifdef NULL_ROOT_CURSOR
> CursorMetricRec cm;
> -#else
> FontPtr cursorfont;
> int err;
> XID fontID;
> -#endif
> -
> -#ifdef NULL_ROOT_CURSOR
> -cm.width = 0;
> -cm.height = 0;
> -cm.xhot = 0;
> -cm.yhot = 0;
> -
> -AllocARGBCursor(NULL, NULL, NULL, &cm, 0, 0, 0, 0, 0, 0,
> - &curs, serverClient, (XID)0);
> -
> -if (curs == NullCursor)
> -return NullCursor;
> -#else
> -fontID = FakeClientID(0);
> -err = OpenFont(serverClient, fontID, FontLoadAll | FontOpenSync,
> - (unsigned)strlen(defaultCursorFont), defaultCursorFont);
> -if (err != Success)
> - return NullCursor;
> -
> -cursorfont = (FontPtr)LookupIDByType(fontID, RT_FONT);
> -if (!cursorfont)
> - return NullCursor;
> -if (AllocGlyphCursor(fontID, 0, fontID, 1, 0, 0, 0, ~0, ~0, ~0,
> - &curs, serverClient, (XID)0) != Success)
> - return NullCursor;
> -#endif
> +
> + if (nullRootCursor) {
> + cm.width = 0;
> + cm.height = 0;
> + cm.xhot = 0;
> + cm.yhot = 0;
> +
> + AllocARGBCursor(NULL, NULL, NULL, &cm, 0, 0, 0, 0, 0, 0,
> + &curs, serverClient, (XID)0);
> +
> + if (curs == NullCursor)
> + return NullCursor;
> + } else {
> + fontID = FakeClientID(0);
> + err = OpenFont(serverClient, fontID, FontLoadAll | FontOpenSync,
> +(unsigned)strlen(defaultCursorFont),
> defaultCursorFont);
> + if (err != Success)
> + return NullCursor;
> +
> + cursorfont = (FontPtr)LookupIDByType(fontID, RT_FONT);
> + if (!cursorfont)
> + return NullCursor;
> + if (AllocGlyphCursor(fontID, 0, fontID, 1, 0, 0, 0, ~0, ~0, ~0,
> +
Re: intel atom support
Carlos Ojea wrote: > Hello! > > I wish to know if there is X support and drivers for intel ATOM processors > ATOM is a CPU not a graphic chip. The Intel board product if that is what you mean has 945 graphics chip on it and works with Xorg. If you are using Linux you might have problems with the realtek network chip. Fixes are in the upcoming 2.6.27 kernel. Barry ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
