Re: [PATCH 2/4] X event queue mutex
On Fri, 2008-10-03 at 05:57 +0300, Daniel Stone wrote: > On Thu, Oct 02, 2008 at 06:53:09PM -0700, Keith Packard wrote: > > On Fri, 2008-10-03 at 02:01 +0200, Simon Thum wrote: > > > (b) may suffice. Locking the queue in OsBlockSigs() should do it and fix > > > most miEnqueue users. > > > > Or just lock the queue in mieqEnqueue itself; keeping the lock near the > > code seems like a lot better plan to me. > > Except if the lock is held across the entire event processing, because > we need to queue events from event processing. That makes it more important that the mutex cover precisely the values which will be modified in multiple threads, inserting events into the queue, and not pulling them out, which is done only in a single thread. -- [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: Need PCI express 16 video card capable of 1680x1050 resolution
On Wed, 01 Oct 2008 10:58:50 -0700, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-30 at 07:49 -0700, Paul White wrote: >> I have a new Dell Inspiron computer with built-in Intel 82G33/G31 video. >> The Intel driver apparently doesn't recognize this specific chipset and >> defaults to using vesa, which doesn't support my monitor's native >> resolution of 1680x1050. >> >> Is there any work being done to support this 82G33 chipset? > > G33 is supported in at least version 2.4.2 of the intel driver, and > possibly earlier. > >> If not, can anyone recommend a specific, currently available, X.org >> supported video card that will fit an available PCI express x16 (or PCI >> express x1) slot and work with my monitor? I don't need 3D graphics. > > Any given radeon or geforce. > > - ajax OK, I have more information on the problem now. 1. FreeBSD 7.0 doesn't include the intel driver by default. I had to build it from sources before I could try it. After installing the intel driver I ran Xorg -configure again, and it recognized the Intel built-in video card. But now, when starting X, it fails with the following errors: From Xorg.0.log: ... (II) LoadModule: "intel" (II) Loading /usr/local/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.4.0, module version = 2.1.1 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 2.0 ... (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) (WW) intel(0): /dev/agpgart is either not available, or no memory is available for allocation. Using pre-allocated memory only. (==) intel(0): VideoRam: 7164 KB (==) intel(0): Write-combining range (0xfdf0,0x8) was already clear (==) intel(0): Write-combining range (0xfda0,0x4) was already clear (II) intel(0): Attempting memory allocation with tiled buffers and large DRI memory manager reservation: (II) intel(0): Allocating 6060 scanlines for pixmap cache (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Attempting memory allocation with tiled buffers and small DRI memory manager reservation: (II) intel(0): Allocating 6060 scanlines for pixmap cache (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Attempting memory allocation with untiled buffers and large DRI memory manager reservation: (II) intel(0): Allocating 6249 scanlines for pixmap cache (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (II) intel(0): Attempting memory allocation with untiled buffers and small DRI memory manager reservation: (II) intel(0): Allocating 6249 scanlines for pixmap cache (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (WW) intel(0): Not enough video memory. Disabling DRI. (II) intel(0): Allocating 6249 scanlines for pixmap cache (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low? (EE) intel(0): Couldn't allocate video memory Fatal server error: AddScreen/ScreenInit failed for driver 0 I googled around for a while for clues, and just for the heck of it I changed the bios settings on my machine to allocate 1MB for the video aperture instead of the default 8MB. This time I was able to start X without complaint and I saw the correct resolution on (parts of) the screen, but the video was very weird and blocky below the first 1/8th (?) portion of the display. I set the aperture back to 8MB and am back where I started. (From scanpci -v): pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x29c2 Intel Corporation 82G33/G31 Express Integrated Graphics Controller CardVendor 0x1028 card 0x027d (Dell, Card unknown) STATUS0x0090 COMMAND 0x0007 CLASS 0x03 0x00 0x00 REVISION 0x02 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xfdf0 addr 0xfdf0 MEM BASE1 0xff01 addr 0xff00 I/O BASE2 0xd008 addr 0xd000 MEM PREFETCHABLE BASE3 0xfda0 addr 0xfda0 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x10 BYTE_00x09 BYTE_1 0x00 BYTE_2 0x0b BYTE_3 0x01 What is agpgart? What do I need to make this work? Thanks again, Paul White ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
On Thu, Oct 02, 2008 at 06:53:09PM -0700, Keith Packard wrote: > On Fri, 2008-10-03 at 02:01 +0200, Simon Thum wrote: > > (b) may suffice. Locking the queue in OsBlockSigs() should do it and fix > > most miEnqueue users. > > Or just lock the queue in mieqEnqueue itself; keeping the lock near the > code seems like a lot better plan to me. Except if the lock is held across the entire event processing, because we need to queue events from event processing. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
On Fri, 2008-10-03 at 02:01 +0200, Simon Thum wrote: > It may be constructed, but IMO this means the queue size is not fully > utilizable given head is 'old': Yes, that's fairly common in queues -- you often can't use the last entry. Not a huge deal if you make the queue big enough. > BTW, given SMP visibility, isn't it a tiny bit risky to have 3 > 'independent' miEventQueue.head reads in miEnqueue? Given the old 'SIGIO' based code, it didn't matter. Even now, it doesn't really matter as in the worst case we fail to store an event when the queue is nearly full but the server is processing events. > (b) may suffice. Locking the queue in OsBlockSigs() should do it and fix > most miEnqueue users. Or just lock the queue in mieqEnqueue itself; keeping the lock near the code seems like a lot better plan to me. -- [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: [PATCH 2/4] X event queue mutex
Keith Packard wrote:
> On Thu, 2008-10-02 at 18:58 -0300, Tiago Vignatti wrote:
>> Keith Packard escreveu:
>>> The input queue is written so that each user modifies only one of the
>>> two pointers (head and tail). There shouldn't be any need to have a
>>> mutex which protects both of these values together, and doing so
>>> prevents mouse motion while the server is processing events.
>> Yeah, but the input thread can change the tail pointer while the main
>> thread is reading that, doing dirty things.
>
> That won't be a problem on any SMP machine where writes from one CPU are
> visible to the other CPU. The key is to have each thread writing only
> one of the two values, and we have that already.
It may be constructed, but IMO this means the queue size is not fully
utilizable given head is 'old':
else {
newtail = (oldtail + 1) % QUEUE_SIZE;
if (newtail == miEventQueue.head) {
ErrorF("[mi] EQ overflowing. The server is probably stuck "
"in an infinite loop.\n");
return;
}
miEventQueue.tail = newtail;
}
It might make sense to increase QUEUE_SIZE when threaded (I'm unaware of
any reasoning behind the current size).
BTW, given SMP visibility, isn't it a tiny bit risky to have 3
'independent' miEventQueue.head reads in miEnqueue?
> So, we either need to fix the users of checkForInput along with all
> users of miEventQueue, or we need to assert that we're running on a
> sensible CPU that doesn't require a mutex to make memory changes visible
> across processors, in which case we don't need any mutex at all.
At XDS, we identified 2 scenarios:
a) Full block of input processing (halt IT at defined state)
b) block enqueuing on IT-side (so e.g. XTest can guarantee order)
(b) may suffice. Locking the queue in OsBlockSigs() should do it and fix
most miEnqueue users.
Given that more input-related stuff is going to be done in input
properties (which are processed on the main thread), (a) may be the only
viable option in some circumstances (If I'm the only, let's forget it).
Then we'd also need to assert visibility of writes when the IT is to
continue. I don't know how to do that pthready however.
Processing input properties on the input thread may avoid that (a) crap
altogether. (cc'ed peter for that). If I didn't miss something, this and
(b) should get the job done.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xlib: extension "Generic Event Extension" missing on display ":0.0".
On Thu, Oct 02, 2008 at 07:35:10AM -0700, Yan Seiner wrote: > >> Xlib: extension "Generic Event Extension" missing on display ":0.0". > (Unless I don't know enough to know better. Should I be concerned about > this?) No, and I've been meaning to silence this warning anyway. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
On Thu, 2008-10-02 at 19:10 -0300, Tiago Vignatti wrote: > Simon Thum escreveu: > > I believe tiagos words are a bit misleading: The mutex makes it possible > > to block event enqueuing, which is needed to guarantee order of events > > enqueued on the main thread. If I got it right, the intent is to > > 'emulate' OsBlockSignals(), though I'm missing that bit. > > Good point, Simon. I forgot about this discussion which we had in XDS. > > Given that there's only one thread to take care about all the input > devices this would not be a problem with *devices*. Events will be > serialized is this case. But the problems eventually can happen if the > others guys that enqueue events (nested servers, DGA, maybe also XTest) > try to do it at the same time with the devices. A mutex is needed in > this situation. Ah, yes indeed -- we need a mutex to protect writes to the tail pointer in mieqEnqueue. But, not the tail reads from mieqProcessInputEvents. That is what the signal blocking stuff was for, after all. -- [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: [PATCH 2/4] X event queue mutex
On Thu, 2008-10-02 at 18:58 -0300, Tiago Vignatti wrote: > Keith Packard escreveu: > > The input queue is written so that each user modifies only one of the > > two pointers (head and tail). There shouldn't be any need to have a > > mutex which protects both of these values together, and doing so > > prevents mouse motion while the server is processing events. > > Yeah, but the input thread can change the tail pointer while the main > thread is reading that, doing dirty things. That won't be a problem on any SMP machine where writes from one CPU are visible to the other CPU. The key is to have each thread writing only one of the two values, and we have that already. > And doing mutex will _not_ prevent the cursor update on the screen while > the server is processing the events. The update is done before the > routines of event enqueue, so no mutex there. The input thread will block before enqueuing while the X server pulls events out of the queue, causing it to stop reading events and updating the cursor. The X server also reads the input queue pointers from DIX before calling into ProcessInputEvents, so you aren't safe against memory write races (where writes to one location are visible across CPUs before writes to another location). So, we either need to fix the users of checkForInput along with all users of miEventQueue, or we need to assert that we're running on a sensible CPU that doesn't require a mutex to make memory changes visible across processors, in which case we don't need any mutex at all. -- [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: [PATCH 2/4] X event queue mutex
Simon Thum escreveu: > I believe tiagos words are a bit misleading: The mutex makes it possible > to block event enqueuing, which is needed to guarantee order of events > enqueued on the main thread. If I got it right, the intent is to > 'emulate' OsBlockSignals(), though I'm missing that bit. Good point, Simon. I forgot about this discussion which we had in XDS. Given that there's only one thread to take care about all the input devices this would not be a problem with *devices*. Events will be serialized is this case. But the problems eventually can happen if the others guys that enqueue events (nested servers, DGA, maybe also XTest) try to do it at the same time with the devices. A mutex is needed in this situation. But yeah, I really have to carefully trace these weird paths to guarantee nothing bad occurs. Thank you, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Compose sequences that produce more than one character
Hi All, I am opening a new side-discussion about layouts, and specifically the issue about compose sequences that have to produce more than one character. Some background: $ echo ' : "X.Org rocks!"' >> ~/.XCompose $ setenv GTK_IM_MODULE xim $ gedit When you press '*' in gedit, you get 'X.Org rocks!'. A more serious use for this feature is for compose sequences such as : "t́" # is actually 't' and the diacritic mark acute (0x301). It's two characters! Currently, keyboard layouts for scripts that no precomposed Unicode characters exist, use the diacritic marks verbatim. For example, there is some key on the keyboard that produces a verbatim acute '0x301'. So, if you press a, and then verbatim acute, you get á, which is actually two characters. If you use GNOME, you can insert this 'verbatim acute' with Type a, then Ctrl+Shift+u, then type 301, them press Space. The issue here is that a user can type many such acutes, and get nice results such as the a and the w in http://www.flickr.com/photos/simosx/2278982091/ This means that the layout cannot limit the number of consecutive diacritic marks. Is there a rational not to have compose sequences that output more than one characters? Or, is it something that just did not caught on yet? Simos ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Keith Packard escreveu: > The input queue is written so that each user modifies only one of the > two pointers (head and tail). There shouldn't be any need to have a > mutex which protects both of these values together, and doing so > prevents mouse motion while the server is processing events. Yeah, but the input thread can change the tail pointer while the main thread is reading that, doing dirty things. At least this is the theory and I'm not 100% sure if this really impacts a real problem on the practical (for instance, today I removed the mutex and executed the server all the day long in a SMP machine without any apparent issue). And doing mutex will _not_ prevent the cursor update on the screen while the server is processing the events. The update is done before the routines of event enqueue, so no mutex there. > Is there something fundamentally different between threaded input and > SIGIO- or kernel-based input that I'm missing here? Besides performance, no. Basically this a replacement feature and eventually locking the cursor's footprint in memory (my next adventure) will solve all the problems of the universe. Thanks for reviewing it, Keith. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] Intel Releases IGD OpRegion Specification
The Intel Open Source Technology Center is pleased to announce the immediate availability of the ACPI Integrated Graphics Device OpRegion Specification[1] under the Creative Commons Attribution-No Derivative Works 3.0 United States License. This document is intended for use by graphics drivers developers and users to enable features such as ambient light sensor support and hotkey-driven display output switching. The IGD OpRegion interface is supported by video BIOS for all Intel® 965 Express Chipset family and newer chipsets. Initial support code is already available for the Linux kernel. The spec includes detailed descriptions of IGD OpRegion functions, APIs, and other interfaces to provide full software support. This release demonstrates Intel's continued commitment to supporting the free software community using the best practices of open source software development. [1] http://www.intellinuxgraphics.org/documentation.html -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transient windows
Juliusz Chroboczek wrote: > > behind the transient principle, the documentation that I've found is > > light and examples aren't many on the web or won't go too deep into the > > matter. I don't know if you have any link to suggest me, if any, I'd be > > glad. > > ICCCM, Section 4.1.2.6. > > The ICCCM is a complex matter, and most tutorials you'll find on the > subject are incorrect. You really should read the ICCCM (as well as > the freedesktop.org wm-spec) rather than trying to browse the web for > information. Also, bear in mind that a lot of software simply ignores the ICCCM. The handling of Alt/Meta by certain GUI toolkits is a prime example. -- Glynn Clements <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transient windows
Jérôme Guilmette wrote:
> I just hope I'm writing to the right mailing list to ask about
> development using the X Window System, if not, please redirect me.
> Here's my situation:
>
> I'm currently developing a software that is taking images from a
> selected X window in order to process the data and put it back in a
> different window. I'm doing a XGetImage() on a backing pixmap to avoid
> the overlapping and "out of sight" windows effects and I'm now
> interested to follow up the windows mapped from my processed window. By
> example, when I put the mouse over one of the window's buttons, a small
> window is appearing or when I slide through the window's menu, menu
> windows are mapped. Those windows are very interesting because they are
> part of the same application and my software would be incomplete without
> them.
>
> I first thought that those windows were created by the "mother" on which
> I'm doing data processing but I discovered that many of them are only
> mapped, like if they were previously created. After doing a XQueryTree
> on windows mapped from the processed window menu, I saw that their
> parent is in fact the root window itself. So there is no way I can tell
> that this window is in fact called by my processed window.
Windows aren't created by another window, they are created by a
client.
> After yet another search, I discovered that those windows are what is
> called "transient" windows and many windows like pop-ups or dialog boxes
> are in fact transients. I still don't clearly understand the ideas
> behind the transient principle, the documentation that I've found is
> light and examples aren't many on the web or won't go too deep into the
> matter. I don't know if you have any link to suggest me, if any, I'd be
> glad.
The concept of a "transient" window is essentially a matter of
convention rather than having any signficant technical basis. The
concept refers to a window with the WM_TRANSIENT_FOR property set to
the XID of another window.
The exact consequences of setting this property depend upon the window
manager (WM) in use, but the window may have fewer buttons in the
title bar, and the transient window may be iconified automatically if
the window referred to by the WM_TRANSIENT_FOR property is itself
iconified.
More details on standard properties can be found in the Inter-Client
Communication Conventions Manual (ICCCM).
Windows which don't have a title bar, border etc (e.g. popup menus,
tooltips) are typically override-redirect windows. This means that the
WM doesn't "manage" them.
Whereas the transient-for property is simply a property attached to a
window, and is only effective insofar as the WM pays attention to it,
the override-redirect flag is part of the core X protocol. If a window
has this flag, any requests to map, unmap, move, resize, raise or
lower the window are acted upon directly, rather than being delegated
("redirected") to the WM.
> So I would like to know if there is a way to know from any type of
> windows created from the processed window, that this window is in fact
> called from the application that is mapped on the processed window. By
> example, to know that the "File or Tools menu window" is in fact created
> by the application running on the processed window. Knowing this, I'd be
> able to take this newly mapped window, take the data and process them.
> Is this related with the transient property or to another one?
You can determine the client which created a window (or pixmap,
cursor, or anything else referenced by an XID) from the XID itself. An
XID is split into a client part and a resource part, similar to the
way that IP addresses are split into network and host parts.
You can find how XIDs are allocated amongst clients using
XResQueryClients(), e.g. (link with -lXRes):
#include
#include
#include
int main(void)
{
Display *dpy;
int num_clients;
XResClient *clients;
int i;
dpy = XOpenDisplay(NULL);
if (!dpy)
return 1;
XResQueryClients(dpy, &num_clients, &clients);
for (i = 0; i < num_clients; i++)
{
XResClient *c = &clients[i];
printf("%08x %08x\n", c->resource_base, c->resource_mask);
}
return 0;
}
For a given client, all XIDs which refer to objects created by that
client will have "(xid & ~c->resource_mask) == c->resource_base"
evaluate to true.
A client can obtain its own resource base and mask from the "Display"
structure, e.g.:
#include
...
struct _XDisplay *priv;
...
priv = (struct _XDisplay *) dpy;
printf("self: %08x %08x\n", priv->resource_base, priv->resource_mask);
This will allow you to determine whether a pa
Re: Transient windows
> behind the transient principle, the documentation that I've found is > light and examples aren't many on the web or won't go too deep into the > matter. I don't know if you have any link to suggest me, if any, I'd be > glad. ICCCM, Section 4.1.2.6. The ICCCM is a complex matter, and most tutorials you'll find on the subject are incorrect. You really should read the ICCCM (as well as the freedesktop.org wm-spec) rather than trying to browse the web for information. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
Christian Pössinger wrote: Hi, > I figured out the UseFBDev function yesterday. When enabling this specific > function my screen shows up with the mighty X cursor. I can move it with Does it also happen when using the SwCursor option? > my mouse perfectly, but the background is only black. I can't see the > normal b/w X background. When I start the xterm it's black, too. It appears as if the driver is writing to one address, and the kernel to other. If you run something like: # dd if=/dev/urandom of=/dev/fb0 bs=1024 count=1024 does it show something on the screen? Please open a bugreport on bugs.freedesktop.org, and also test the latest git master. Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Transient windows
Hi X gurus and developers, I just hope I'm writing to the right mailing list to ask about development using the X Window System, if not, please redirect me. Here's my situation: I'm currently developing a software that is taking images from a selected X window in order to process the data and put it back in a different window. I'm doing a XGetImage() on a backing pixmap to avoid the overlapping and "out of sight" windows effects and I'm now interested to follow up the windows mapped from my processed window. By example, when I put the mouse over one of the window's buttons, a small window is appearing or when I slide through the window's menu, menu windows are mapped. Those windows are very interesting because they are part of the same application and my software would be incomplete without them. I first thought that those windows were created by the "mother" on which I'm doing data processing but I discovered that many of them are only mapped, like if they were previously created. After doing a XQueryTree on windows mapped from the processed window menu, I saw that their parent is in fact the root window itself. So there is no way I can tell that this window is in fact called by my processed window. After yet another search, I discovered that those windows are what is called "transient" windows and many windows like pop-ups or dialog boxes are in fact transients. I still don't clearly understand the ideas behind the transient principle, the documentation that I've found is light and examples aren't many on the web or won't go too deep into the matter. I don't know if you have any link to suggest me, if any, I'd be glad. So I would like to know if there is a way to know from any type of windows created from the processed window, that this window is in fact called from the application that is mapped on the processed window. By example, to know that the "File or Tools menu window" is in fact created by the application running on the processed window. Knowing this, I'd be able to take this newly mapped window, take the data and process them. Is this related with the transient property or to another one? Any help or direction to documentation on the matter would be greatly appreciated. Thank you very much, Jérôme ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Whence be libXevie tarball?
On Thu, Oct 2, 2008 at 11:41:34 -0500, Pat Kane wrote: >Package evieproto was not found in the pkg-config search path. >Perhaps you should add the directory containing `evieproto.pc' >to the PKG_CONFIG_PATH environment variable >No package 'evieproto' found > > The only reason I need it is to avoid that error message. Is there > a way to tell X server not to need evieproto? > evieproto != libXevie. The former is at http://xorg.freedesktop.org/archive/X11R7.4/src/proto/evieext-1.0.2.tar.bz2 Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Whence be libXevie tarball?
On Thu, Oct 2, 2008 at 9:41 AM, Pat Kane <[EMAIL PROTECTED]> wrote: > On Fri, Sep 26, 2008 at 9:27 AM, Daniel Stone <[EMAIL PROTECTED]> wrote: > > Xevie is pretty much deprecated. What are you using it for? > > I am trying to build the X server from tarballs[1] and I get this error msg: > > Building xserver module component xorg-server... > configure: WARNING: you should use --build, --host, --target > appending configuration tag "CXX" to libtool > appending configuration tag "F77" to libtool > configure: error: Package requirements (randrproto >= 1.2 renderproto > fixesproto >= 4.0 damageproto >= 1.1 xcmiscproto xextproto > xproto >= 7.0.9 xtrans scrnsaverproto >= 1.1 bigreqsproto > resourceproto fontsproto inputproto >= 1.4.4 kbproto >= 1.0.3 videoproto > compositeproto >= 0.4 resourceproto xineramaproto evieproto xkbfile xfont > xau fontenc pixman-1 >= 0.9.5 xdmcp) were not met: > > Package evieproto was not found in the pkg-config search path. > Perhaps you should add the directory containing `evieproto.pc' > to the PKG_CONFIG_PATH environment variable > No package 'evieproto' found > > The only reason I need it is to avoid that error message. Is there > a way to tell X server not to need evieproto? I think --disable-xevie should do it. Maybe this should be the default since XEvIE is on the way out as Daniel says. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Whence be libXevie tarball?
On Fri, Sep 26, 2008 at 9:27 AM, Daniel Stone <[EMAIL PROTECTED]> wrote: > Xevie is pretty much deprecated. What are you using it for? I am trying to build the X server from tarballs[1] and I get this error msg: Building xserver module component xorg-server... configure: WARNING: you should use --build, --host, --target appending configuration tag "CXX" to libtool appending configuration tag "F77" to libtool configure: error: Package requirements (randrproto >= 1.2 renderproto fixesproto >= 4.0 damageproto >= 1.1 xcmiscproto xextproto xproto >= 7.0.9 xtrans scrnsaverproto >= 1.1 bigreqsproto resourceproto fontsproto inputproto >= 1.4.4 kbproto >= 1.0.3 videoproto compositeproto >= 0.4 resourceproto xineramaproto evieproto xkbfile xfont xau fontenc pixman-1 >= 0.9.5 xdmcp) were not met: Package evieproto was not found in the pkg-config search path. Perhaps you should add the directory containing `evieproto.pc' to the PKG_CONFIG_PATH environment variable No package 'evieproto' found The only reason I need it is to avoid that error message. Is there a way to tell X server not to need evieproto? Pat [1] http://xorg.freedesktop.org/archive/X11R7.4/src/ On Fri, Sep 26, 2008 at 9:27 AM, Daniel Stone <[EMAIL PROTECTED]> wrote: > On Fri, Sep 26, 2008 at 09:20:43AM -0500, Pat Kane wrote: >> I see libXevie in the git tree at git://anongit.freedesktop.org/git >> but not in the tarballs at: http://xorg.freedesktop.org/archive/X11R7.4/src/ >> am I missing something? > > Xevie is pretty much deprecated. What are you using it for? > > Cheers, > Daniel > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkjc8WwACgkQUVYB1rKAgJQXuwCfU1zlmQtvMKEurzpjTlaTV1UD > NmAAn0lbQrOMU1oV1OB3+o9wGpAoiJLn > =OZ3E > -END PGP SIGNATURE- > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xfbdev color problems due to endianess
I got back to this after working on some other things for a while and
I've made some progress. I looked at an old version of xfree that we
had since old with the endian problems fixed and tried to apply the
changes to xorg 7.3 (see diff form normal xorg 7.3 and my patched
version below) and it did help somewhat. Before I had problems with
"dirt" in for example xeyes and fonts being displaced (they looked ok,
they were just moved to the left) and this were fixed, but I still
have problems with the colours looking off.
Since the changes did fix it for the old xfree 4.5.0 I'm guessing
there's some new parts in xorg7.3 that I would have to patch in
similar manner? Anyone got any pointers of where that could be?
Thanks
/Leon
--- xs_x11/xorg_true/xserver/include/servermd.h 2008-09-16
01:44:34.0 +0200
+++ x11_color/xorg_true/xserver/include/servermd.h 2008-09-29
12:37:54.0 +0200
@@ -257,8 +257,12 @@
/* linux on ARM */
#if defined(linux) && defined(__arm__)
+/*
#define IMAGE_BYTE_ORDER LSBFirst
#define BITMAP_BIT_ORDER LSBFirst
+*/
+#define IMAGE_BYTE_ORDER MSBFirst
+#define BITMAP_BIT_ORDER MSBFirst
#define GLYPHPADBYTES 4
#endif
--- xs_x11/xorg_true/xserver/miext/shadow/shadow.h 2008-09-16
01:44:33.0 +0200
+++ x11_color/xorg_true/xserver/miext/shadow/shadow.h 2008-09-29
12:22:34.0 +0200
@@ -24,6 +24,8 @@
#ifndef _SHADOW_H_
#define _SHADOW_H_
+#define ccpxsswap(x) (((x >> 8) & 0x00FF00FF) | ((x << 8) & 0xFF00FF00))
+
#include "scrnintstr.h"
#ifdef RENDER
--- xs_x11/xorg_true/xserver/miext/shadow/shpacked.c2008-09-16
01:44:33.0 +0200
+++ x11_color/xorg_true/xserver/miext/shadow/shpacked.c 2008-09-29
12:24:24.0 +0200
@@ -103,7 +103,11 @@
scr += i;
#define PickBit(a,i) (((a) >> (i)) & 1)
while (i--)
- *win++ = *sha++;
+ {
+ /* *win++ = *sha++;*/
+ *win++ = ccpxsswap(*sha);
+ sha++;
+ }
}
shaLine += shaStride;
y++;
--- xs_x11/xorg_true/xserver/miext/shadow/shplanar8.c 2008-09-16
01:44:33.0 +0200
+++ x11_color/xorg_true/xserver/miext/shadow/shplanar8.c2008-09-29
12:26:26.0 +0200
@@ -161,7 +161,8 @@
GetBits(plane,2,s2);
GetBits(plane,4,s3);
GetBits(plane,6,s4);
- *win++ = s1 | (s2 << 8) | (s3 << 16) | (s4 << 24);
+ /**win++ = s1 | (s2 << 8) | (s3 << 16) | (s4 << 24);*/
+ *win++ = ccpxsswap(s1 | (s2 << 8) | (s3 << 16) | (s4 <<
24));
sha += 8;
}
}
--- xs_x11/xorg_true/xserver/miext/shadow/shplanar.c2008-09-16
01:44:33.0 +0200
+++ x11_color/xorg_true/xserver/miext/shadow/shplanar.c 2008-09-29
12:27:30.0 +0200
@@ -159,7 +159,8 @@
GetBits(plane,1,s2);
GetBits(plane,2,s3);
GetBits(plane,3,s4);
- *win++ = s1 | (s2 << 8) | (s3 << 16) | (s4 << 24);
+ /**win++ = s1 | (s2 << 8) | (s3 << 16) | (s4 << 24);*/
+ *win++ = ccpxsswap(s1 | (s2 << 8) | (s3 << 16) | (s4 <<
24));
sha += 4;
}
}
--- xs_x11/xorg_true/xserver/miext/shadow/shrotate.c2008-09-16
01:44:33.0 +0200
+++ x11_color/xorg_true/xserver/miext/shadow/shrotate.c 2008-09-29
12:28:40.0 +0200
@@ -288,7 +288,8 @@
}
sha += shaStepOverY;
}
- *win++ = bits;
+ /**win++ = bits;*/
+ *win++ = ccpxsswap(bits);
}
}
scr_y++;
--- xs_x11/xorg_true/xserver/hw/kdrive/vesa/vesa.c 2008-09-16
01:44:41.0 +0200
+++ x11_color/xorg_true/xserver/hw/kdrive/vesa/vesa.c 2008-10-02
11:10:03.0 +0200
@@ -758,7 +758,7 @@
{
bits = *sha++;
vesaInvertBits32(bits);
- *win++ = bits;
+ *win++ = ccpxsswap(bits);
}
}
shaLine += shaStride;
On Wed, Sep 10, 2008 at 3:05 PM, Leon Ljunggren
<[EMAIL PROTECTED]> wrote:
> Hi,
> I have compiled and got kdrive (Xfbdev), using the latest stable
> source from git, running on my ARM based system but I'm experiencing
> problems with colours., they are "inverted". This is casued by the
> fact that my machine is big endian while the gfx module is little
> endian. This means that:
>
> BGGR
>
> becomes
>
> GGGRBGGG
>
> In fbdev.c there's a color masking feature (in
> fbdevScreenInitialize(...), line 264-266), that I thought I could
> modify to fix the problem:
>
> screen->fb[0].redMask = Mask (3, 5);
> screen->fb[0].green
Re: compilation error on xorg-xserver git head
Am Donnerstag 02 Oktober 2008 schrieb Julien Cristau: > You need to update xtrans. Ok, seems there are only some small changes in xtrans, would it make sense to have a new release? (to make it easier for people to try out gem) -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED] http://freiheitstattangst.de/ - 11.10. Berlin gegen Überwachung http://x1000malquer.de/ - ab 8.11. Atomtransporte stoppen 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/4] X event queue mutex
On Thu, 2008-10-02 at 10:36 +0200, Simon Thum wrote: > I believe tiagos words are a bit misleading: The mutex makes it possible > to block event enqueuing, which is needed to guarantee order of events > enqueued on the main thread. If I got it right, the intent is to > 'emulate' OsBlockSignals(), though I'm missing that bit. That sounds fine, but the patch also serializes with dequeuing events. -- [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: Xlib: extension "Generic Event Extension" missing on display ":0.0".
Julien Cristau wrote: > On Thu, Oct 2, 2008 at 07:18:48 -0700, Yan Seiner wrote: > > >> I've recently started running xorg 1.5.0 from debian experimental. I >> keep getting this error: >> >> Xlib: extension "Generic Event Extension" missing on display ":0.0". >> >> > Where does your libX11.so.6 come from? This message means that Xlib has > XGE support, but the server doesn't. libx11 in Debian is 1.1.5, which > doesn't know about XGE. > Yup, that's it. I'll just wait for debian to get caught up. It doesn't seem to be doing any harm. (Unless I don't know enough to know better. Should I be concerned about this?) --Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [sugar] rendering test
Michel Dänzer wrote: >> As a result of ee7c684f21d, the PutImage hook in ShmFuncs is no longer >> being used. Shall I commit a cleanup? > > ShmPutImage is still accelerated though (also, that commit is only in > 1.5, not 1.4). What kind of cleanup do you have in mind? Remove the unused PutImage hook from the ShmFuncs structure. Also maybe move the whole structure definition in the xserver as it doesn't seem like something that belongs to the public xextproto interface. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xlib: extension "Generic Event Extension" missing on display ":0.0".
On Thu, Oct 2, 2008 at 07:18:48 -0700, Yan Seiner wrote: > I've recently started running xorg 1.5.0 from debian experimental. I > keep getting this error: > > Xlib: extension "Generic Event Extension" missing on display ":0.0". > Where does your libX11.so.6 come from? This message means that Xlib has XGE support, but the server doesn't. libx11 in Debian is 1.1.5, which doesn't know about XGE. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xlib: extension "Generic Event Extension" missing on display ":0.0".
I've recently started running xorg 1.5.0 from debian experimental. I keep getting this error: Xlib: extension "Generic Event Extension" missing on display ":0.0". It doesn't appear to do any harm but it's annoying. The only thing I've been able to find is this: http://archive.netbsd.se/?ml=xorg-team&a=2008-05&t=7493915 which is not really applicable, as everything I have is 1.5.0: [EMAIL PROTECTED]:/data/home/pictures/Panasonic/2008-09-14$ head /var/log/Xorg.0.log (WW) Failed to open protocol names file /etc/X11/xserver/protocol.txt X.Org X Server 1.5.0 Release Date: X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.17.7 x86_64 Debian Current Operating System: Linux selene 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64 Build Date: 04 September 2008 11:37:30AM xorg-server 2:1.5.0-1 ([EMAIL PROTECTED]) Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Can anyone shed any light on this? Is this a debian packaging problem or should I be chasing down something on my system? Thanks, --Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: compilation error on xorg-xserver git head
On Thu, Oct 2, 2008 at 16:03:13 +0200, Hanno Böck wrote: > I wanted to try out gem and tried to compile xorg-xserver from git: > You need to update xtrans. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
compilation error on xorg-xserver git head
I wanted to try out gem and tried to compile xorg-xserver from git:
Making all in os
make[1]: Entering directory
`/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/os'
../doltcompile
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include-DHAVE_DIX_CONFIG_H
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE
-DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE
-I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include-I../include
-I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi
-I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -O2
-march=nocona -pipe -MT
connection.lo -MD -MP -MF .deps/connection.Tpo -c -o connection.lo
connection.c
In file included from connection.c:108:
osdep.h:95:5: error: missing binary operator before token "("
make[1]: *** [connection.lo] Error 1
make[1]: Leaving directory
`/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/os'
make: *** [all-recursive] Error 1
The code lines are:
#if OPEN_MAX <= 256
#define MAXSOCKS (OPEN_MAX - 1)
#else
#define MAXSOCKS 256
#endif
My assumption is that if OPEN_MAX is not set, the #if line returns bogus (#if
<= 256), so one should probably add some check if OPEN_MAX is set at all. My
C-preprocessor skills are limited, so I can't come up with a ready-made
patch.
--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED]
http://freiheitstattangst.de/ - 11.10. Berlin gegen Überwachung
http://x1000malquer.de/ - ab 8.11. Atomtransporte stoppen
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] RFC: remove repeater functionality from xf86-input-synaptics
I would like to propose to remove the repeater functionality completely from
the synaptics touchpad driver. It is buggy in its current implementation
and its usefulness is questionable.
According to the INSTALL file, the repeater is there only for testing. In
fact, if a supported device is found even a configured repeater fifo is
automatically disabled. For most users the functionality is therefore
irrelevant and can be confusing. If I understand the workings of the
repeater correctly, a developer could instead just read the data directly
from an unsupported device's character special file under /dev
or /dev/input.
With today's more dynamic device configuration possibilities via udev and
hal it's also less likely that the synaptics driver would silently block
another devices data, this situation being for what the repeater
functionality seems to have been introduced in the past.
Please review the attached patch and apply if appropriate.
Best Regards,
Magnus Kessler
Remove repeater fifo from synaptics driver
Signed-off-by: Magnus Kessler <[EMAIL PROTECTED]>
diff --git a/INSTALL b/INSTALL
index d385450..47d2913 100644
--- a/INSTALL
+++ b/INSTALL
@@ -48,11 +48,9 @@ Section "InputDevice"
Option "MinSpeed" "0.09"
Option "MaxSpeed" "0.18"
Option "AccelFactor" "0.0015"
-# Option "Repeater" "/dev/ps2mouse"
EndSection
Change the Identifier to the same name as in the ServerLayout section.
-The Option "Repeater" is at the moment for testing.
5. Add the "CorePointer" option to the InputDevice line at the
ServerLayout section:
diff --git a/src/synaptics.c b/src/synaptics.c
index 7b5e6d5..148b3f6 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -498,30 +498,6 @@ static void set_default_parameters(LocalDevicePtr local)
}
}
-static void set_repeater_fifo(LocalDevicePtr local)
-{
-SynapticsPrivate *priv = local->private;
-pointer optList;
-char *repeater;
-int status;
-
-repeater = xf86SetStrOption(local->options, "Repeater", NULL);
-if (repeater) {
- /* create repeater fifo */
- status = mknod(repeater, 666, S_IFIFO);
- if ((status != 0) && (status != EEXIST)) {
- xf86Msg(X_ERROR, "%s can't create repeater fifo\n", local->name);
- } else {
- /* open the repeater fifo */
- optList = xf86NewOption("Device", repeater);
- if ((priv->fifofd = xf86OpenSerial(optList)) == -1) {
- xf86Msg(X_ERROR, "%s repeater device open failed\n", local->name);
- }
- }
- free(repeater);
-}
-}
-
/*
* called by the module loader for initialization
*/
@@ -607,9 +583,6 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
priv->comm.buffer = XisbNew(local->fd, 200);
DBG(9, XisbTrace(priv->comm.buffer, 1));
-priv->fifofd = -1;
-set_repeater_fifo(local);
-
if (!QueryHardware(local)) {
xf86Msg(X_ERROR, "%s Unable to query/initialize Synaptics hardware.\n", local->name);
goto SetupProc_fail;
@@ -977,18 +950,6 @@ static Bool
SynapticsGetHwState(LocalDevicePtr local, SynapticsPrivate *priv,
struct SynapticsHwState *hw)
{
-if (priv->fifofd >= 0) {
- /* when there is no synaptics touchpad pipe the data to the repeater fifo */
- int count = 0;
- int c;
- while ((c = XisbRead(priv->comm.buffer)) >= 0) {
- unsigned char u = (unsigned char)c;
- write(priv->fifofd, &u, 1);
- if (++count >= 3)
- break;
- }
- return FALSE;
-}
return priv->proto_ops->ReadHwState(local, &priv->synhw, priv->proto_ops,
&priv->comm, hw);
}
@@ -2225,19 +2186,9 @@ QueryHardware(LocalDevicePtr local)
if (priv->proto_ops->QueryHardware(local, &priv->synhw)) {
para->synhw = priv->synhw;
- if (priv->fifofd != -1) {
- xf86CloseSerial(priv->fifofd);
- priv->fifofd = -1;
- }
return TRUE;
}
-if (priv->fifofd == -1) {
- xf86Msg(X_ERROR, "%s no synaptics touchpad detected and no repeater device\n",
- local->name);
- return FALSE;
-}
-xf86Msg(X_PROBED, "%s no synaptics touchpad, data piped to repeater fifo\n", local->name);
priv->proto_ops->DeviceOffHook(local);
return TRUE;
}
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index e5202d1..cc0a29f 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -95,7 +95,6 @@ typedef struct _SynapticsPrivateRec
OsTimerPtr timer; /* for up/down-button repeat, tap processing, etc */
struct CommData comm;
-int fifofd; /* fd for fifo */
SynapticsMoveHistRec move_hist[SYNAPTICS_MOVE_HISTORY]; /* movement history */
int hist_index; /* Last added entry in move_hist[] */
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] xf86-input-synaptics: fix creation of repeater fifo
On Monday 29 September 2008, Peter Hutterer wrote: > On Sun, Sep 28, 2008 at 03:11:46PM +0100, Magnus Kessler wrote: > > Testing status against EEXIST is wrong and we should check errno > > instead if we want to allow the use of an existing file. However, since > > we pass a file name that in principle could be any existing file (not > > just fifos) is there any guarantee that we can later actually use the > > fifo? > > Thanks. There is no guarantee that we can use it, but at the same time > the use-case where the pipe already exists is common. > In the simple case of a server restart, the first mkfifo command succeeds > but the second fails with EEXIST. So the pipe is still there and should > be used. Admittedly, it might be a good idea to clean up after ourselves > and delete the fifo if we have created it in the first place. What about > the (compile-tested) code below? > > Cheers, > Peter > [patch snipped] Hi Peter, your patch would certainly work and prevent fifos created by the driver hang around if and when the X server terminated normally. Crashes would still lead to the current situation. I'm also slightly nervous about adding yet more code to functionality that is effectively never used in normal operations. New proposal to follow... Cheers, Magnus 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: Synaptics and the scroll zone after resume from suspend.
On Thu, Oct 02, 2008 at 12:44:29PM +0100, Colin Guthrie wrote: > Now what to do I wonder... as /dev/input/event2 does actually exist.. I > wonder if it's a timing thing? It probably is. I don't know how to get around that though other than adding the synaptics options to your fdi file and letting HAL do the job. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Synaptics and the scroll zone after resume from suspend.
Peter Hutterer wrote: > On Thu, Oct 02, 2008 at 10:12:40AM +0100, Colin Guthrie wrote: >> I'm using xf86-input-synaptics-0.15.2 and wonder if other users have a >> problem with the scroll zone after resuming from suspend. >> >> For me it just stops working which is pretty annoying. Does anyone know >> how to help diagnose and/or fix? > > Do you have the device configured in your xorg.conf? Yes. Section "InputDevice" Identifier "SynapticsMouse1" Driver "synaptics" Option "SHMConfig" "on" EndSection > If so, check the log, it might not come back properly after resume and the > device is added through HAL instead. In this case, the options specified in > the fdi file are the ones used, not the ones in the xorg.conf. Ahhh bingo: (EE) xf86OpenSerial: Cannot open device /dev/input/event2 No such file or directory. (WW) SynapticsMouse1: cannot open input device couldn't enable device 2 (II) Mouse1: ps2EnableDataReporting: succeeded Now what to do I wonder... as /dev/input/event2 does actually exist.. I wonder if it's a timing thing? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Virtual core keyboard
2008/10/2 Peter Hutterer <[EMAIL PROTECTED]>: > On Tue, Sep 30, 2008 at 02:44:26PM +0100, John Tapsell wrote: >> I have a device without a keyboard, but I still send keyboard events >> to X. Specifically I use synergy. > > what version of X are you running? I used the version from HEAD in git. I had the same problem with kdrive however. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Virtual core keyboard
On Tue, Sep 30, 2008 at 02:44:26PM +0100, John Tapsell wrote: > I have a device without a keyboard, but I still send keyboard events > to X. Specifically I use synergy. what version of X are you running? > Is there a way to add some sort of 'virtual' keyboard? X server 1.4 and above always have a virtual keyboard, it's hardcoded in the startup procedure and cannot be removed. Last I checked synergy was still working but that's a few months ago now. Unless we broke it since, it could be a problem with your setup. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Software for calibrating a touch screen
On Wed, Oct 01, 2008 at 11:45:03AM +0200, Søren Hauberg wrote: > Good point. Perhaps the recently added 'invert_[x|y]' options in the > evdev driver should be removed? Perhaps not, as such an option might > be generally usable. I think it is a feature worth having. The cost of maintainance is low enough to not worry about it, even if it is used little. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Synaptics and the scroll zone after resume from suspend.
On Thu, Oct 02, 2008 at 10:12:40AM +0100, Colin Guthrie wrote: > I'm using xf86-input-synaptics-0.15.2 and wonder if other users have a > problem with the scroll zone after resuming from suspend. > > For me it just stops working which is pretty annoying. Does anyone know > how to help diagnose and/or fix? Do you have the device configured in your xorg.conf? If so, check the log, it might not come back properly after resume and the device is added through HAL instead. In this case, the options specified in the fdi file are the ones used, not the ones in the xorg.conf. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Synaptics and the scroll zone after resume from suspend.
Hi, I'm using xf86-input-synaptics-0.15.2 and wonder if other users have a problem with the scroll zone after resuming from suspend. For me it just stops working which is pretty annoying. Does anyone know how to help diagnose and/or fix? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Keith Packard wrote: > On Wed, 2008-10-01 at 21:39 -0300, Tiago Vignatti wrote: > >> A mutex is needed because the X event queue is a critical region. Though >> the X event queue is re-entrant, we cannot guarantee the simultaneous >> processing by both main and input threads. > > The input queue is written so that each user modifies only one of the > two pointers (head and tail). There shouldn't be any need to have a > mutex which protects both of these values together, and doing so > prevents mouse motion while the server is processing events. > > Is there something fundamentally different between threaded input and > SIGIO- or kernel-based input that I'm missing here? I believe tiagos words are a bit misleading: The mutex makes it possible to block event enqueuing, which is needed to guarantee order of events enqueued on the main thread. If I got it right, the intent is to 'emulate' OsBlockSignals(), though I'm missing that bit. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SMI 501 local bus driver
On Wed, 1.10.2008, 20:53, Paulo Cesar Pereira de Andrade wrote: > > Does the kernel framebuffer work? In that case, there is a fallback > option "UseFBDev", that will not attempt to program the hardware, other > then the accel registers. I figured out the UseFBDev function yesterday. When enabling this specific function my screen shows up with the mighty X cursor. I can move it with my mouse perfectly, but the background is only black. I can't see the normal b/w X background. When I start the xterm it's black, too. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
