Re: [Xpert]Decimal key on European keyboard layouts
Robin Rosenberg <[EMAIL PROTECTED]> writes: > fredagen den 13 december 2002 02.12 skrev Christian Rose: > > Hi! > > > > When I press "," (the decimal symbol key) on the numerical part of my > > Swedish keyboard in XFree86, I get a "." (point). This is obviously > > wrong, as it should be a comma, the decimal symbol that is used in > > Sweden and what this key is labeled with on Swedish standard keyboards. > > > > I've checked some other keyboard layouts and others for which the > > decimal key on the numeric keypad is a comma is as follows: > > Finland (identical to the Swedish layout), Denmark, Netherlands, Norway, > > Switzerland, Germany. I suspect that these may be wrongly defined as > > point too. > > > > Anyone else seen this? Suggestions? > > It seems this is a feature (i.e. a documented bug) of X11, > The keypad decimal key is mapped to KP_Decimal which is a symbolic key, translated > somewhere on the application side. > The workaround is xmodmap -e "keycode 91 = comma". I notice some keymaps (cz,sk) > have fixed this, although they have commented the fix as inappropriate. > > So, where is KP_Decimal translated to "." ? .Xdefaults can be used for some >applications (XLIb?, xterm etc) > but not others (GTK, QT). The default GTK+ input method uses a big table of Keysym => Unicode translations, originally based on work by Markus Kuhn. Probably that table needs a runtime exception for KP_Decimal Just filed a bug on it: http://bugzilla.gnome.org/show_bug.cgi?id=101225 Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Linux 8.0 - Replacing Gnome with XDM
"Mike A. Harris" <[EMAIL PROTECTED]> writes: > In /etc/sysconfig/desktop, set: > > DISPLAYMANAGER=xdm Actually, I think this needs to be XDM (all caps) It should all be pretty transparent if you look at /etc/X11/prefdm, in any case. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CRTL-ALT-BACKSPACE broken
Mark Vojkovich <[EMAIL PROTECTED]> writes: > On Thu, 28 Nov 2002, Mark Vojkovich wrote: > > > > > As Alan mentioned earlier, this does seem to be broken. I just > > synced up on PPC and find that none of the CRTL-ALT- keys work > > anymore. Can't quit with CTRL-ALT-BS, can't switch VTs. > > > > There have been modifications by Marc and David to xf86Events.c > > during the last week. David's specifically modifies CTRL-ALT behavior. > > Marc's puts some #ifdefs around related code, but the logic > > doesn't look suspect. > > > >Are we the only ones seeing this? I just synced up and made World > again, and made sure I got rid of my host.def so that I didn't have > any stale configuration around. I still can't do any CTRL-ALT-XXX. I was seeing the same problem, and for me the problem turned to be that I had a XKB definition file that I was using instead of the standard keyboard maps, so when the special server actions were changed to work via XKB, they simply weren't there in my configuration. What I was doing was pretty unusual ... perhaps you simply have XKB turned off in your XF86Config? Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RH Linux 8.0 - Chips 69030 - Cursor and and keys freeze
Herman Buel <[EMAIL PROTECTED]> writes: > RH Linux 8.0 - Chips 69030 - Cursor and and keys freeze > > On a new install, the pc will boot and the cursor and KBD freezes almost >immediately. The same hardware and setting worked fine under RH 7.0 (XFree 4.01) > & 7.3 (XFree 4.2.0). > > Any idea what the problem might be ? A quick web search reveals: http://www.dtims.com/support/document_central/application_notes/an001.html Which looks very similar. So you might want to try adding the "SWCursor" option. No idea why things worked for you with Red Hat 7.3. If that works, could you file a bug in bugzilla.redhat.com with the details ... we can set things up to automatically add that option for cards with a certain PCI id. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Eric Deveaud <[EMAIL PROTECTED]> writes: > On Thu, 21 Nov 2002, Scott Lampert wrote: > > > Is there a simple way to get X to use larger or different mouse cursors? > > in current cvs tree you can set Xcursor.size to differents values. > > > I run at very high resolutions 1800x1440+ and it gets > > difficult to find the mouse cursor without whipping it all over the > > screen sometimes. > > quite thee same situation here. I'm using 3200x1200 (Xinerama), and > sometimes I "loose the cursor" > my whish would be to have a key combo to hilihgt the cursor, something > like pinpoint on macosx > http://macchampion/pinpoiny_screenshots.shtml> > > is there a way do the same There is an equivalent feature in GNOME-2.0. I just broke my GTK+ installation, so I can't look up what it's called or what the key combo is, but you can turn it on in the mouse preferences dialog. (You hit the key combo, you get a little animation around the mouse cursor) Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]FW: Lots of IP traffic, no screen activity - WOW! Exp erts in deed.
[EMAIL PROTECTED] writes: > Thanks for the responses! > > I hadn't thought of font translation in the mix. Perhaps since both of my > examples internally are RH 8, this isn't as much of a problem? How often > does this occur? Once per session or every time a screen has to be > refreshed? > > I will try to do another experiment with your suggestions to see what the > results are. OK, this is just a complete guess, since you don't say _what_ applications you are trying to remote display. (If they are custom applications, what toolkit?). But to give a guess: With Red Hat 8, if you are seeing horrible performance, one definite possibility is that you are are using client-side emulation of antialiasing. That is, rendering of of antialiased fonts using Xft is quite efficient in bandwidth/latency if you have the RENDER extension on the server. But if not, then the way that antialiasing is done is to get the image from the server, composite, and put it back, so a round trip for each rendering operation. So, using a Red Hat 8 application over an ISDN line to an old X server is expected to be really, really, slow. You can try turning off antialiasing in the GNOME font properties dialog and see if that helps ... expect things to look awful, however. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]solution to slow window move/resize problem
Jouni Tulkki <[EMAIL PROTECTED]> writes: > Hello > > I have experimented with lwm (light weight window manager). I had noticed > that moving windows with the mouse so that window position is updated > immediately when mouse is moved was slow. After trying different > ways to reduce the slow response to window move/resize I > realized that the problem could be reduced by putting a limit to the > frequency of moving and resizing windows. I found 50Hz to be a proper > frequency for window moving on my system, but a slower frequency might be > needed on slower systems. For window resize I use 25Hz. > > Some have argued that the real problem is that many applications are badly > written. Properly written X application should compress expose and > configure events. However many applications don't do this and this results > in slow responsiveness of the system when moving and resizing windows. > > While my solution may not solve the real problem, it does help the > situation with current applications. Also there is no reason to update > windows position/size faster then 50Hz because the eye cannot percieve any > significant difference between 50Hz and a higher frequency. > > I haven't tested the latest KDE and Gnome desktops so I don't know if they > already do this. I think you'll find if run X with the '-dumbSched' option, things may behave a lot better without the rate limitation. There is a problem with the XFree86 scheduling algorithm that tends to cause window managers to starve applications. (Clients that get mouse events and don't do much drawing get prioritized above clients that don't get mouse events and do a lot of drawing) Last time I talked to Keith about this, he had the idea that perhaps when one client configures the window of another client, the priority of the second client should be increased. To really get things good, however, the window manager actually needs to be able to tell when the client is done handling a particular resize... this would require more substantial architectural changes. Not to say that rate limitation isn't useful sometimes, but I think it's basically just working around this scheduling bug. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
Xavier Bestel <[EMAIL PROTECTED]> writes: > Le dim 03/11/2002 à 18:47, Keith Packard a écrit : > > Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > > > Oh, and are there any opinions about the signal to use, SIGALRM or > > > something else? > > > > You'll have to make it settable -- SIGALRM is already used by the X server > > for scheduling. Of course, we could eliminate that if I could get the > > current time of day mapped into the X server address space :-) > > Just synchronizing from time to time and using TSC in the meantime isn't > sufficient ? Note that SMP issues make using the TSC safely really hard .. TSC's aren't synchronized between processors on SMP systems, and a process could get migrated at any time. I think the Linux kernel people aren't yet sure if it's possible to do a safe non-syscall high-resolution gettimeofday() for these reasons. Making the signal settable is definitely the right thing to do in any case. What the /dev/rtc driver does is hook into SIGIO so it can use fnctl (fd, F_SETSIG, ...); that setup could probably be copied, though there may be better ways of doing it. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Michel Dänzer <[EMAIL PROTECTED]> writes: > On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: > > Yes, XSYNC has the right things to allow applications to synchronize > > on arbitrary things (including vertical sync). > > > > If the fbdev and/or DRI folks are willing to support and export an interface, > > it should be possible to get the plumbing hooked up. > > > > Just make it a file descriptor we (and/or other things) can select against, > > and it should be something that can be pretty cross platform without much > > trouble: them's that don't implement it on a given platform won't get > > support... > > The interface we've implemented in the DRM is an ioctl which basically > blocks for a requested number of vertical blanks (it's more flexible in > fact). Maybe a daemon or something could provide a file descriptor to > select against? Both select and a blocking ioctl are really the wrong interface here. select() or poll() are problematical because select() waits for a condition, not an event. That is, these function calls are designed things like "tell me when there is more data to read". The blocking ioctl is a pain because it means you have to devote a thread to waiting for the VBI; but it at least is well defined. Unix signals are another possibility - a real pain to program, but at least they were designed for things like this. "Tell me when the next VBI occurs" has very similar semantics to alarm(2). Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X process redirection...
Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > JG> So making GTK/gnome apps migrate is within reach. > > That's excellent news. > > What happens to pixmaps and client-side data structures when the depth > changes? Emacs doesn't have this problem as it can safely mutate data > structures that are only accessible to clients through Lisp objects. An application written for GTK+-2.0 will typically have no user-visible server side resources. Fonts and images are client side. If a custom widget or specialized application is creating server-side resources (cursors, pixmaps), then it needs to create them in a ::realize handler, and destroy them in a ::unrealize handler. So, it's automatic for the typical case, and needs a bit of programmer intervention for less typical cases. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem with Xft and pango
Vladimir Dergachev <[EMAIL PROTECTED]> writes: > On Sat, 3 Aug 2002, Keith Packard wrote: > > > > > Around 14 o'clock on Aug 3, Fred Heitkamp wrote: > > > > > I'm trying to compile the latest CVS pango version. > > > Is this possible? > > > > Yes, but you need to make sure you've added the FreeType2 header directory > > to the include path so that you get FreeType2 headers instead of FreeType1. > > Right. The problem is that freetype2 headers are (for my system) in > > /usr/local/include/freetype2/freetype > > and was compiling freetype2 source myself. So one needs to add > -I/usr/local/include/freetype2 > to CFLAGS or do > ln -s /usr/local/include/freetype2/freetype /usr/local/include/freetype > > Neither seems right.. Does anyone know a better way ? The freetype2 headers aren't the problem ... Pango will get the right include flags from freetype-config, the problem is your freetype1 headers. See, e.g.: http://mail.gnome.org/archives/gtk-i18n-list/2002-April/msg9.html Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xmove without xmove?
Vladimir Dergachev <[EMAIL PROTECTED]> writes: > > > I'm curious whether the functionality of xmove and > > > similar programs -- redirecting an X client to another > > > display -- can be reproduced without having something > > > like the xmove pseudoserver that intercepts the > > > state-creating operations. > > > > > > Is it possible instead to recover the state just before > > > redirection by querying the server and perhaps > > > rummaging through Xlib's data in the client? > > > > > > I picked a simple example, pixmaps, and could not find > > > a way to do this, but I'd love to hear otherwise. > > > > It really requires toolkit cooperation (and to a lesser > > extent app cooperation) ... we have it working currently in > > the development branch of GTK+. > > > > Without that, it's not even theoretically possible, because > > you don't know where the toolkit might/app have stored the > > ID referring to a window on the original display. > > What about having per-connection Window ID translation table ? > This could be done entirely in Xlib.. Well, at the 90% level you could probably do something in this fashion; but remember that XIDs can be stuck inside client messages or properties, so X can't tell reliably what is an XID and what is not. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xmove without xmove?
vic <[EMAIL PROTECTED]> writes: > I'm curious whether the functionality of xmove and > similar programs -- redirecting an X client to another > display -- can be reproduced without having something > like the xmove pseudoserver that intercepts the > state-creating operations. > > Is it possible instead to recover the state just before > redirection by querying the server and perhaps > rummaging through Xlib's data in the client? > > I picked a simple example, pixmaps, and could not find > a way to do this, but I'd love to hear otherwise. It really requires toolkit cooperation (and to a lesser extent app cooperation) ... we have it working currently in the development branch of GTK+. Without that, it's not even theoretically possible, because you don't know where the toolkit might/app have stored the ID referring to a window on the original display. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Questsions on current status and future
Joseph Pingenot <[EMAIL PROTECTED]> writes: > Hello. > > I'm somewhat new to in-depth X-ness, but I've been following a usenet > thread, and the following post came up: > [I apologize if my in-depth-newbieness shows through; please be patient :] > > "I wish X11 were good enough I could resolve 2 real world problems my company > is having with it's use. > > 1) Some older custom written (contractor) X11 apps served from a Big Endian > OS that pukes when Xinput can't provide a Big Endian response back from an > X86 Linux boxen. There is no source code, and the contractor is no longer > in business. The app has no commercial equivalent. It's sounds like one of two things: - A buggy XInput implementation in the "Big Endian OS's" libXi - A buggy XInput implementation in the XFree86 server It's more likely to be the first; though I wouldn't deny the possibility of the second. The X protocol hides virtually all endianess issues from clients. (You do mean XInput? graphics tablets?) There is nothing that can done about this other than fix the bugs. > 2) With a fixed 60ms delay between remote sites, a Remote X11 Client/Server > application takes almost a second per mouse (xinput) selection for a > database app just for a menu response to manifest itself at the display. > The same app locally is instantaneous. The problem is bi-directional > because X11 is non-asynchronous multiple transactions with it's X11 > client/server handshaking (font, colors, geometry, xinput, menu population, > etc.). At 60ms per handshake, it adds up to unacceptable application delay. > The solution seems to be only to access a remote Windows 2000 Terminal > Server (using ICA/RDP) that has a local proximity X11 server to the X11 > application host, and deal with a single compressed stream of ICA display > data across the WAN." This basically means a badly written toolkit or application. With a properly written toolkit, it's very seldom that the toolkit needs to retrieve data from the server. (You say that "X11 is non-asynchronous" but actually the X protocol is about as asynchronous as you can get, and Xlib exposes a good deal of that asynchronicity to applications and toolkits. That doesn't mean that toolkits can't do stupid things.) General rule: - Round trips bad ... latency is the killer - Pushing lots of data through the connection doesn't matter much Putting the toolkit on the server side might well make things worse because the application *does* need to get information from the toolkit quite frequently. (That being said, I'm a little skeptical of ever having good interactive GUI performance over a WAN ... once latency gets up beyond 20-30ms a Java-applet style architecture is most likely going to be the best way to have things be snappy.) Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]S3 Graphics Twister K Compaq
"Mikael Olenfalk" <[EMAIL PROTECTED]> writes: > Hi Xperts! > > > I bought a Compaq EVO n115 some time ago, and I just felt like > exchanging this * Windows XP Home with a little bit more powerful > GNU/Linux and - of course - XFree86 ;). > > Just everything went fine until I came to configuring XFree86. > > It was even impossible for me to startup the graphical configuration > system. > > Every time I launched X it told me I have a S3 card but XF86 can't > recognize the CARD ID (i.e. unsupported card). > > When I later installed XP Home again :( I can see in Windows that the > card is referred to as "S3 Graphics Twister K Compaq". > > A few days ago I have to call the Compaq support, as my laptop used to > overheat and turn off after some hours of work (less than 5). I referred > my problem to him - without expecting any proper answer ;) - about the > missing driver for XF86 for the S3 Card/Chip. This guy was funnily > enough amused by my problem as the specs showed him, that they do not > deliver S3 cards with their evo n115 laptops. The specs says I (uu-huuh) > have a "VIA ProSavage KN133". > > > Does anybody know what shall I do to get my S3 Graphics Twister K Compaq > card to work in XF86? VIA bought S3 some time ago, explaining the name discrepancy. Relevant information for figuring out why it isn't identified would be: - The version of XFree86 (and the version of your distribution) - The PCI ID of the card. (/sbin/lspci -v will give you that.) The current Savage driver lists a large number of PCI ID's for various cards, but it would not be inconceivable that what you have is a special version for Compaq with yet a different PCI ID... such things are known to happen. (You might also want to try checking if the "savage" driver is explicitely listed in your XF86Config-4 as a simple first step; if not, listing it could conceivably help.) Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PrintScreen/SysRq and Pause/Break
Owen Taylor <[EMAIL PROTECTED]> writes:
> Unless anybody objects to the above reasoning, I'm going to
> submit a patch that:
>
> * Changes xf86PostKbdEvent() to force convert keycodes
>KEY_SysReqest => KEY_Print and KEY_Break => KEY_Pause
>
> * Changes the supplied xkb maps to remove the mappings
>for the SYRQ and BRK keycodes.
>
> (This should cause no compatibility problems for applications,
> since applications should never be hardcoding keycodes.
> It might cause some small compatibility problems for people's
> custom keymaps if they are hardcoding keycodes, but the current
> situation is broken enough that I think it's worth that
> incompatibility.)
Here's the patch as promised. It works as expected.
Possible concerns:
- There may be some very rare PC keyboards that use the
SysRq/Break scancodes in different ways.
The czsk keyboard description distributed with XFree86
has:
key {
type= "PC_BREAK",
symbols[Group1]= [ Pause, Break ]
};
key {[ Multi_key ] };
I have no idea if this is accurate, or a mistake in the
keymap, but since czsk hasn't existed since 1993
(cz and sk are fine), I'm not very concerned.
- On non-PC platforms, it's conceivable that Pause/Break
could be on different keys and have legitimately different
key codes. Any problems here could probably be solved
with the right #ifdef.
From what I've seen, virtually all current keyboards
are based on the PC keyboard for these keys.
Despite these minor potential problems, I think the change
is definitely right:
- It fixes an obvious problem for the vast majority of
XFree86 users.
- It's impossible to develop fixes for potential fringe
cases without going ahead, making the change, and seeing
if anybody complains.
I'll send this to [EMAIL PROTECTED], but wanted to send it
here as well for more chance for comments.
Regards,
Owen
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.sysreq Fri Nov 30 07:11:54 2001
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c Fri Jul 5 22:03:16 2002
@@ -776,6 +776,17 @@
#endif /* SCO */
/*
+ * PC keyboards generate separate key codes for
+ * Alt+Print and Control+Pause but in the X keyboard model
+ * they need to get the same key code as the base key on the same
+ * physical keyboard key.
+ */
+ if (scanCode == KEY_SysReqest)
+scanCode = KEY_Print;
+ else if (scanCode == KEY_Break)
+scanCode = KEY_Pause;
+
+ /*
* Now map the scancodes to real X-keycodes ...
*/
keycode = scanCode + MIN_KEYCODE;
--- xc/programs/xkbcomp/symbols/czsk.sysreq Thu Oct 4 09:12:05 2001
+++ xc/programs/xkbcomp/symbols/czsk Fri Jul 5 22:03:17 2002
@@ -290,11 +290,6 @@
symbols[Group1]= [ Print, Sys_Req ]
};
-key {
-type= "PC_SYSRQ",
-symbols[Group1]= [ Print, Sys_Req ]
-};
-
key {
type= "PC_BREAK",
symbols[Group1]= [ Pause, Break ]
--- xc/programs/xkbcomp/symbols/jp.sysreq Wed Jan 17 18:45:58 2001
+++ xc/programs/xkbcomp/symbols/jp Fri Jul 5 22:03:17 2002
@@ -101,19 +101,11 @@
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Execute ]
};
-key {
- type= "PC_SYSRQ",
- symbols[Group1]= [ Print, Execute ]
-};
key { [ Scroll_Lock ] };
key {
type= "PC_BREAK",
symbols[Group1]= [ Pause, Break ]
};
-key {
- type= "PC_BREAK",
- symbols[Group1]= [ Pause, Break ]
-};
key { [ Insert ] };
key { [ Home ] };
key { [ Prior ] };
--- xc/programs/xkbcomp/symbols/us.sysreq Fri Aug 17 09:27:58 2001
+++ xc/programs/xkbcomp/symbols/us Fri Jul 5 22:03:17 2002
@@ -112,19 +112,11 @@
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
-key {
- type= "PC_SYSRQ",
- symbols[Group1]= [ Print, Sys_Req ]
-};
key { [ Scroll_Lock ] };
key {
type= "PC_BREAK",
symbols[Group1]= [ Pause, Break ]
};
-key {
- type= "PC_BREAK",
- symbols[Group1]= [ Pause, Break ]
-};
key { [ Insert ] };
key { [ Home ] };
key { [ Prior ] };
--- xc/programs/xkbcomp/symbols/us_group2.sysreq Mon Oct 1 10:04:16 2001
+++ xc/programs/xkbcomp/symbols/us_group2 Fri Jul 5 22:03:17 2002
@@ -116,19 +116,11 @@
type= "PC_SYSRQ",
symbols[Group2]= [], [ Print, Sys_Req ]
};
-key {
- type= "PC_SYSRQ",
- symbols[Group2]= [], [ Print, Sys_Req ]
-};
key { [], [ Scroll_Lock ] };
key {
type= "PC_BREAK",
symbols[Group2]= [], [ Pause, Break ]
};
-key {
- type= "PC_BREAK",
- symbols[Group2]= [], [ Pause, Break ]
-};
key { [], [ Insert ] };
key { [], [ Home ] };
[Xpert]PrintScreen/SysRq and Pause/Break
On PC keyboards, XFree86 generates different key _codes_
for:
PrintScreen and Alt+PrintScreen == SysRq
and for:
Pause and Control+Pause == Break
This is an inheritance of a PC keyboard oddity -- different
key codes are actually generated. But XFree86 should cover up
for this oddity,rather than propagating it.
Reasons:
A) If you remap Alt or Control, then the keycodes don't
follow along. On my keyboard, I map both Control and
Caps Lock to Control_L, but:
Pause giveskeycode 110 == Pause
Caps Lock + Pause gives control + keycode 110 == Break
Control + Pause gives control + keycode 114 == NoSymbol
B) Multiple keycodes per phyical key don't correspond to
the Core X or XKB model of how keyboards work.
C) XKeysymToKeycode() and XKeycodeToKeysym() don't work.
As an excerpt from the standard XFree86 XKB mapping:
key {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
key {
type= "PC_SYSRQ",
symbols[Group1]= [ Print, Sys_Req ]
};
You get:
XKeysymToKeycode (XKeycodeToKeysym (SYRQ)) == Print
(Or, depending on ordering, it might be:
XKeysymToKeycode (XKeycodeToKeysym (PRSC)) == SYRQW)
This means it's very hard to XGrabKey() on PrintScreen
correctly.
Unless anybody objects to the above reasoning, I'm going to
submit a patch that:
* Changes xf86PostKbdEvent() to force convert keycodes
KEY_SysReqest => KEY_Print and KEY_Break => KEY_Pause
* Changes the supplied xkb maps to remove the mappings
for the SYRQ and BRK keycodes.
(This should cause no compatibility problems for applications,
since applications should never be hardcoding keycodes.
It might cause some small compatibility problems for people's
custom keymaps if they are hardcoding keycodes, but the current
situation is broken enough that I think it's worth that
incompatibility.)
Regards,
Owen
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > MV> DGA really shouldn't be used and I regret that it's still in the > MV> X-server. I would like it to disappear in XFree86 5.0. > > Mark, > > I fully agree with your feeling, and I am sincerely sorry to say what > I'm about to say. > > There is no denying, though, that there are applications that want to > do client-side rendering -- and I think that's a perfectly legitimate > thing to do. The obvious solutions (PutImage and ShmPutImage) either > involve one copy too many, or else require you to put your rendering > buffers in a shared memory segment. > > I may be mistaken, but as far as I can see, the only way to do a > direct blit from a random client-specified buffer is DGA. Unless we > provide a different way to do that, there is little chance of DGA > going away with no loss. If you are willing to give up the "Random" then, you can use ShmPixmaps or ShmImages and have: Blit from framebuffer specified data to screen - XShmPutImage Blit from RGB data to screen - RENDER Blit from YUV, etc to screen - Xv (I know less about the last.) In the cases that this doesn't work, well, the overhead of an extra memory => memory copy is just not all that significant these days. I don't think it is worth throwing away the security and robustness model and using DGA. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow opaque window resizing
Lukas Molzberger <[EMAIL PROTECTED]> writes: > Hello, > I'm using Linux and XFree for quite some time now and I'm a big fan of it. > However, there is one bug that has always annoyed me. When I resize a window > under XFree then it can take a long time until the content of this window is > redrawn. > I've also looked into the Mailing List archieves and found an discussion about > this topic earlier, but it seemed to be without a result: > http://www.xfree86.org/pipermail/render/2001-March/000829.html > I think that it would be good to have this issue fixed for two reasons. First, > it looks ugly and second, for many people resizing a window is a simple way > of testing the performance of a new OS like Linux. I think what you are seeing is a known bug in the XFree86 scheduler: http://www.xfree86.org/pipermail/xpert/2001-August/010435.html Basically, what happens is that X sees: Window manager isn't taking much time to draw and is getting lots of mouse events. Application is taking a lot time to draw and is getting no mouse events. Decides that the application is a badly behaved client and starves it out of existence. Running X with the -dumbSched command line option should improve things a lot. I talked about with this Keith at some point and he thought it should be easy to fix, but I don't remember the details. Like many scheduling problems, it is, fundementally an architectural problem. Ideally, the window manager should wait for the client before processing the next step in the resize; but it's really hard to do this with the Window manager / client separation in X. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Keyboard input.
"Dave Williss" <[EMAIL PROTECTED]> writes: > In porting an X server to Windows or Macintosh, it would be possible > to let the OS handle all the keyboard input stuff and the X server would > just get Unicode. The question is: Is there a standard way to let the > X Server pass the client application Unicode values directly? No, the X protocol deals with: a) Physical keyboard keys b) A mapping presented to clients between those physical keyboard keys and abstract "key symbols" It's legitimate for clients to do things like treat a press of "1 = !" the same as a press of "1" because they are on the same key, or watch presses and releases of the Control key. The correct thing to do would be to "reverse engineer" the OS's keyboard map and expose that in an unchangeable fashion via XKB or the core protocol keyboard map. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]unicode input
"James H. Cloos Jr." <[EMAIL PROTECTED]> writes: > Is there any good way to input arbitrary unicode characters via the > keyboard in a en_US.UTF-8 locale? > > I cannot find any sign of an XIM server for this. Everything I've > found seems to be targted to CJK input. > > Is there one that I missed? > > Is there a better way than bothering with an XIM server? Obviously > just adding compose or dead-key sequences to do it would be a bit, > err, extreme (65536 lines at OTOO 54 octets per line is 3 3/8 megs). Well, depends what system you are using... with GTK+-2.0, you can do arbitrary Unicode entry using: [hex digits] However, in general for programs that only allow XIM input methods, you'd need an XIM input method that supported something like that. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]latest CVS xfree and gtk2 apps fail to find font--old libXrender bug back again?
mikepolniak <[EMAIL PROTECTED]> writes: > Just updated to latest cvs version 4.2.99.1 and trying to load pan(newsreader) with > GDK_USE_XFT=1 gives: > > ** ERROR **: Failed to match any font. This could be due to a broken Xft >configuration, or if you run XFree 4.1.0 due to a bug in libXrender. For more >information about this, read http://bugzilla.gnome.org/show_bug.cgi?id=68030 > > aborting... > > This bug was fixed for 4.2.0 but apparently is back. If i unset GDK_USE_XFT > then pan will load, although without aa fonts. Is there a fix ? Almost certainly what is going on here is "broken Xft configuration" rather than the Xrender bug referenced in the error message. The Xft version 1 library in XFree86 CVS uses a different configuration file than earlier versions of Xft; typically it will be in /etc/fonts/fonts.conf. You might want to look at the output of: strace -e open pan To see what coniguration file it is trying to load, and whether it is finding it. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][CVS] make install: compile fails at lib/fontconfig/src/fccharset.c
"Axel H. Siebenwirth" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I have updated my CVS tree and after a successful build, make install stops
> at a compile failure in lib/fontconfig/src/fccharset.c.
>
> Oh, by the way is there a way to track recent changes via cvs?
Sounds like the typical slackware freetype1-headers-installed-in-the-wrong-place bug.
Regards,
Owen
From: Owen Taylor <[EMAIL PROTECTED]>
Subject: Re: Problem compiling pango 1.0.1
To: Damon Chong <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Date: 06 May 2002 14:44:36 -0400
Damon Chong <[EMAIL PROTECTED]> writes:
> Hi I'm a newbie with Gnome and C/C++ so forgive me if i'm
> wasting your time. I got a bunch of error messages (see
> attached) while trying to compile pango. Any advise
> appreciated. Thank you! ;-)
This (I believe) is a symptom of a Slackware bug. Slackware has the
freetype2 header in:
[includedir]/freetype2/freetype/freetype.h
Which is good, but the freetype1 header is in:
[includedir]/freetype/freetype.h
Which means that when a program includes with a
compile line that includes -I [includedir]/freetype2, it is
indeterminate which one it gets, and depends on what other -I flags
are on the compile line.
The *only* correct fix is for the freetype1 header files to be moved
in the package into a freetype1 sub-directory, and for the few (if any
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Where Should I Be Sending Patches?
Alan Hourihane <[EMAIL PROTECTED]> writes: > Be patient. > > We're all busy with other things, and there are plenty of patches still > waiting in the queue. Please don't resend anything. Can I suggest, as a long term goal, having a publically viewable bug tracker / patch queue? At least from my point of view, the current system isn't working very well. If I find a bug in XFree86 (say, http://bugzilla.gnome.org/show_bug.cgi?id=81783, which turned up 5 minutes ago :-), it's frequently not clear how to proceed. Yes, I can send mail to [EMAIL PROTECTED] or [EMAIL PROTECTED]; b bug report. But in either case it feel like a complete shot in the dark. - I can't check on the status of my bug-report/patch. - I can't give someone else an URL to go to check on the the status. - I can't meaningfully give updates ... sending mail to "[EMAIL PROTECTED]" saying "you know the patch I sent 2 months ago. Forget it, it turns out to have been faulty hardware" at least seems like it won't work very well. - There isn't any reliable way of telling if/when my bug has been applied. - If the person dealing with the bug report / patch wants to get further information, they have communicate with me privately, and I understand very well that something like bugzilla is considerable amount of sysadmin work to set up and maintain that would take away from someone's hacking. And there simply may not be the resources currently. But for GTK+ and GNOME, we find it an extremely valuable tool to have this stuff public ... not a panacea ... I still get plenty of people annoyed at me for slow response to GTK+ patches, but at least they see a milestone for the bug, and know it hasn't been lost. Regards, Owen (bugzilla has mechanisms for restricted visibility for things like security problems or NDA information, so a public bug tracker doesn't mean that you have to give up all privacy.) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + gtk+1.2 freezes
What I would suggest is that you grab xmon from: ftp://ftp.x.org/contrib/devel_tools/xmon.1.5.6.tar.gz (Or, I think Debian might have a package of it.) And run the app under it: xhost + [ I've generally had to do this, standard cautions apply ] xmonui | xmond > /tmp/log DISPLAY=localhost:1 evolution Then up the detail level using the buttons at the top and reproduce the crash... that should give a log of the last few requests that your app made of the X server. Unless you are using a UTF-8 locale, I doubt it has anything specifically to do with UTF-8... those warning messages are internal to evolution. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + gtk+1.2 freezes
Xavier Bestel <[EMAIL PROTECTED]> writes: > I've got problems with some apps using gtk+1.2. They often freeze when > in Xinerama mode. > > My setup is: > Linux 2.4.19-pre7-ac2 (SMP) > Debian/sid > XFree86 4.1.0 > gtk+1.2 > Xinerama mode on 2 different sized screens, one on an ATI R128 and the > other on a S3 Virge. > > I've seen Evolution freeze *very* often (several times a day), Galeon > sometimes, and 1 other simpler app (edonkey gui) once. > > I tried without Xinerama and couldn't reproduce the freezes. > > Here's a bt from an evolution-mail freeze: > > #0 0x411207ce in select () from /lib/libc.so.6 > #1 0x40f7ffdc in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6 > #2 0x40edb3ba in _XRead () from /usr/X11R6/lib/libX11.so.6 > #3 0x40edbdc3 in _XReply () from /usr/X11R6/lib/libX11.so.6 > #4 0x40ed2e1d in XQueryPointer () from /usr/X11R6/lib/libX11.so.6 > #5 0x40e87d38 in gdk_window_get_pointer () from /usr/lib/libgdk-1.2.so.0 > #6 0x40e2f1e7 in gtk_widget_get_pointer () from /usr/lib/libgtk-1.2.so.0 > #7 0x40339415 in e_vpaned_new () from /usr/lib/libgal.so.19 > #8 0x40dc7e3f in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0 > #9 0x40df7013 in gtk_signal_set_funcs () from /usr/lib/libgtk-1.2.so.0 > #10 0x40df50b3 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 > #11 0x40e2bacb in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 > #12 0x40dc7d85 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0 > #13 0x40dc6eee in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 > #14 0x40e76457 in gdk_wm_protocols_filter () from /usr/lib/libgdk-1.2.so.0 > #15 0x4102e4d8 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 > #16 0x4102eae3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 > #17 0x4102ec7c in g_main_run () from /usr/lib/libglib-1.2.so.0 > #18 0x40dc67e7 in gtk_main () from /usr/lib/libgtk-1.2.so.0 > #19 0x40468ebd in bonobo_main () from /usr/lib/libbonobo.so.2 > #20 0x0809e473 in main () > #21 0x4106f14f in __libc_start_main () from /lib/libc.so.6 > > > It seems it freezes always at the same place in the code. The pattern is > common with Galeon: the first 4 lines are the same (from select to > _XReply), then an Xlib function then a gtk function. I can send you a bt > on request (when it freezes again). > > I honestly don't know what to do to help debug that. Please tell me what > I could do (not too destructive for my setup please). The first step would be to try to get a backtrace while running the programs with the --sync command line option, since it's possible that it's not the XQueryPointer that is causing the hang but some earlier request. Unfortunately, I'm not sure if either evolution or Galeon will really pass that option through to the main part of the application ... they are both somewhat complicated. But it's worth trying. And it should definitely work for simpler apps. (You can tell if you are running the apps synchronized, because it will be darn slow.) Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SAVESET extension proposal
Owen Taylor <[EMAIL PROTECTED]> writes: > Here's a proposal for a tiny protocol extension (one request other than > QueryVersion) that would help a lot in making inter-client embedding > robust. > > I'm willing to do the work in implementing this for XFree86, though > I might need help in checking the protocol for sanity and figuring > out how to implement it. (A separate library for one request seems > like overkill, but I'm not sure that adding it to XLib would be > legitimate.) > > Does this proposal make sense? I went ahead and tried implementing my proposed extension; went quite easily as I expected. (This is with 'reparent to root' instead of 'reparent to WINDOW'.) In the functional part of the diff, where I have: - if(!pWin->realized && pWin->mapped) + if(!pWin->realized && pWin->mapped && pTmp->mapAction != SaveSetUnmap) pWin->mapped = FALSE; } - MapWindow(pWin, client); + if (pTmp->mapAction == SaveSetMap) + MapWindow(pWin, client); + else/* SaveSetUnmap */ + UnmapWindow(pWin, FALSE); I'm not sure I quite understand the original pWin->mapped = FALSE, so I'm not so confident in the change, though it seems to work in the limited testing I've done. The comparison of the size of the diff (~1000 lines) with the amount of it (~350 lines) which is not just adding a new extension and a new library certainly supports Keith's opposition to lots of little extensions. Regards, Owen saveset-extension-20020403.diff.gz Description: Initial implementation attempt
[Xpert]Re: SAVESET extension proposal
Keith Packard <[EMAIL PROTECTED]> writes: > > ChangeSaveSetValues > > I think all you need is the ability to reparent to the root. As the > embedded window isn't override-redirect, the remapping will be redirected > giving the window manager a chance to peer at the window. A suitable WM > convention could be developed to get the embedded window moved to its > final resting place. As you say in your proposal, other alternatives > involve significantly more error checking and validation at many points in > the server. Since I don't actually need anything but reparenting to the root, and I can't think of any good reason for reparenting to an arbitrary window, I'm happy to simplify things in that area. I'd rather avoid getting the window manager involved too much here; perhaps the "two's company, three's a crowd" principle applies when trying to make things robust. What I'd like to achieve is that when the embedder dies, the embedding protocol ends simply and cleanly; if we need to extend the X protocol, we might as well solve the problem completely (if it's only a few lines of extra code) rather than also require a new window manager convention, and a cooperating window manager. Also, I think adding window manager conventions like "don't map windows with the _XEMBED_INFO property on them" is a little dubious ... I think conventions are best when, if the window manager doesn't support them the fallback behavior is reasonable. > This would also eliminate the need for x-offset/y-offset values, so the > extension could contain only a single request identical to ChangeSaveSet > with an additional mode (SetModeInsertRoot). The x-offset/y-offset addition is really quite separate thing, with the only connection being that had been pointed out to me as a problem, and it was very easy to fix at the same time. The problem basically is that the ICCCM specifies positioning adjustments on startup and shutdown (gravity point on unmanaged and managed windows should be on the same place) and the shutdown adjustments won't be made if the window manager terminates abnormally. It could certainly be fixed without any X additions if window managers consistently supported looking for some _NET_WM_CRASH_OFFSETS property at start. Ugly, but it certainly better than extending the X protocol just for this reason. But, it seemed to me that if we could fix it easily here we might want to do it. Since the only people who regularly switch window managers, or have their window manager crash notice problems here, and the problems (drifting windows) aren't severe, it's not really a problem for end-users. I'm certainly not strongly attached to either: a) Making it a separate request instead of a ChangeSaveSet replacement b) Using a fixed set of parameters rather than a ChangeGCValues They are just fairly arbitrary protocol design issues; the basic I reasons I had for them were: a) Reuse as much existing API as possible. (And the x-offset/y-offset values are likely to need to be changed if things like the window manager b) There were four parameters that could be set; this is enough that it doesn't seem like a "fixed number", but rather a variable quantity. > Are there other WM related extensions that we could usefully merge with > this extension? I'd like to solve any outstanding issues all at once, > rather than with a zillion tiny extensions. The main other area where I'm aware of where an extension might be needed is in some issues related to selections ... it would take me a while to remember all the issues, but when I was trying to figure out how to fix some of the problems with implementing a full-featured clipboard in X, there were issues that were really hard to deal with without notification of selection ownership changes. This doesn't really seem very related, but I suppose we could make a "client communication" extension that just contained "random" things related to ICCCM / desktop issues and plan to increase the minor number as necessary if we add more stuff in the future. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]SAVESET extension proposal
Here's a proposal for a tiny protocol extension (one request other than
QueryVersion) that would help a lot in making inter-client embedding
robust.
I'm willing to do the work in implementing this for XFree86, though
I might need help in checking the protocol for sanity and figuring
out how to implement it. (A separate library for one request seems
like overkill, but I'm not sure that adding it to XLib would be
legitimate.)
Does this proposal make sense?
Thanks,
Owen
ChangeSaveSetValues
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match
Sets the save-set values for WINDOW. window must be in the client's
save-set or Match error occurs.
The value-mask and value-list contain the attributes to change. The
possible values are:
target: WINDOW or None
map-action: { Nothing, Map, Unmap }
x-offset: INT16
y-offset: INT16
When the client's resources are destroyed, if window is an inferior of a
window
created by the client,window is:
Reparented to the target value window, or if None, to the closest
ancestor such that window is not an inferior of a window created
by the client.
Mapped if map-action is Map, unmapped if map-action is Unmap.
Moved such that if the original root-window location of the client's
upper left corner is x,y then the new location is x + x-offset,
y + y-offset.
The default component values when a window is added to the client's save-set
correspond to the core protocol behavior and are:
Component Default
---
target None
map-action Map
x-offset0
y-offset0
Rationale:
Being able to set the target is important when doing-interclient
embedding as in the XEmbed protocol.
(http://www.freedesktop.org/standards/xembed.html.) If the
embedder is unexpectedly killed, the behavior of the core protocol is to
reparent the client to the window manager's frame and map it. Since the
window manager then destroys its frame, the client window is not saved,
and the client application will likely crash. The client application may
have a separate toplevel (e.g. an application with a status docklet in
the desktop's panel) or windows embedded elsewhere, so this is highly
undesirable.
Setting the map-action so that the window is unnmapped rather than
mapped is desirable to keep the window from temporarily being visible as
a child of the root window. (Note that unmapping and reparented back to
the root window not result in a "lost" window, since this is the normal
termination of the XEmbed protocol and clients are required to watch for
it.)
x-offset and y-offset can be used by a reparenting window manager so
that if it is killed unexpectedly then when a new window manager is
started, windows appear in their original location, rather than offset
by the frame thickness.
Possible Issues:
Allowing the target to be a WINDOW may complicate implementation to
handle the case where the target is destroyed between the
ChangeSaveSaveSetValues call and the client being destroyed. An
alternative which handles the use case is to make it an enumeration with
the possible values { NearestParent, Root }.
The save-set values are per-client, per-window rather than per-window.
I think being per-client is more logical and probably easier to
implement since the save-set itself is per-client.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH]: XftFreetype.h missing typedef struct on XftFontStruct
"bharat tewari" <[EMAIL PROTECTED]> writes: > just curious? why have we seperated the xft code and put it under the pango > directory itself? one of the reasons where i think it will be useful is when > people are using xfree86 3.x series but as such pango checks for the > XftConfig file which will be present only with xfree86 4.1.x and later > versions ( am i right on this?) so why cant we use the Xft library which > come bundled along with xfree86 rather than compiling pango seperately. > since this discussion happened over here i am posting it here, i guess i > should take this discussion on the gtk development list. Pango-1.0 uses Xft code in two different places: - The Xft backend compiles against the system copy of Xft if the system has Xft, and is not built otherwise. - the FT2 backend (which is used for rendering independent of X on all systems) uses a portion of Xft separated out as "MiniXft" for handling font configuration. This setup is designed so that if you have Xft on your system, the two backends share a single configuration file. If you don't have Xft installed then you would have to create an XftConfig file specifically for the FT2 backend, but this is no worse than if the FT2 backends configuration file was called pangoft2.aliases and custom contents. For Pango-1.2, I need to decide between: - Keeping MiniXft/Xft1 support and adding in addition support for new fontconfig library (the official version of MiniXft) and for Xft2. - Require fontconfig and Xft2 for all installations of Pango that want to use the backends. (fontconfig is independent of X, Xft2 supports servers without the RENDER extension.) This would clean up the code a _lot_ and make it a easier to share memory between the two backends, but on the other hand adds yet one dependency to an an already complex build process. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH]: XftFreetype.h missing typedef struct on XftFontStruct
Shawn Starr <[EMAIL PROTECTED]> writes:
> After using a recent CVS snapshot GTK+'s pango failed to configure
> properly with errors:
>
> configure: WARNING: X11/Xft/XftFreetype.h: present but cannot be compiled.
> configure: WARNING: X11/Xft/XftFreetype.h: check for missing prerequisite headers?
> configure: WARNING: X11/Xft/XftFreetype.h: proceeding with the preprocessor's result
>
> Error in config.log:
>
> In file included from configure:16193:
> /usr/X11R6/include/X11/Xft/XftFreetype.h:77: parse error before '*' token
> /usr/X11R6/include/X11/Xft/XftFreetype.h:78: warning: type defaults to `int' in
>declaration of `XftFreeTypeOpen'
>
>
> Solution: Add typedef struct, error gone.
>
> Shawn.
>
>
> Patch below:
>
>
> --- XftFreetype.h.old Tue Mar 19 23:36:27 2002
> +++ XftFreetype.h Tue Mar 19 23:28:10 2002
> @@ -57,6 +57,8 @@ struct _XftFontStruct {
>
> _XFUNCPROTOBEGIN
>
> +typedef struct _XftFontStruct XftFontStruct;
> +
> /* xftdir.c */
> Bool
> XftDirScan (XftFontSet *set, const char *dir, Bool force);
Pango's Xft support simply doesn't work with current XFree86 CVS which
has a substantially different version of Xft (version 2) from the one that
Pango expects.
Keith has some patches to get it working, see:
http://mail.gnome.org/archives/gtk-devel-list/2002-February/msg00321.html
I hope to work on integrating them into Pango CVS within the next few
weeks.
Regards,
Owen
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]can X11 die more slowly ?
Mark Vojkovich <[EMAIL PROTECTED]> writes: > On Sun, 3 Mar 2002, Gniazdowski Mariusz wrote: > > > Hi. > > > > Sometimes it happens - work in some vi, staroffice, gimp etc etc and bum - > > "Signal 11 server crash"... With Mandrak8.1 it happens very rarely, > > however it happens. > > > > So, are there chances to make it look like "Hey XFree did receive signal > > X11, save your work and prepare to shut down" ? > >From the client's point of view there's little difference between > the X-server segfaulting and someone hitting the little 'X' button > that the window manager puts next to the title bar (for most window > managers, the 'X' is equivalent to xkill - the connection to the > server is severed). Luckily there is actually a protocol in the ICCCM for the window manager to the send the application a polite request to shutdown, and this is what the 'X' typically does, though many window managers will also have an option for more forceful xkill style termination. (After all, the app should have the option to put up a dialog about saving unsaved files, or whatever.) >Any client can install a handler via Xlib to respond to this > occurance. Most don't. They probably should given how the same > problem would happen just by "closing" the window. Unfortunately, it's very hard to react to losing the connection to the X server cleanly... the error handler you install is not allowed to return, so basically all you can do is hope that your app is sufficiently reentrant from whatever place was making the X call to allow you to do an autosave. (Interaction with the user is clearly not possible.) This, BTW, makes it impossible to write an X app that robustly connects to multiple displays and cleans up when it loses the connection to one of them... I think Jim said something about having plans to fix this at some point. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
[EMAIL PROTECTED] (Jim Gettys) writes: > Owen: > > This is certainly true: but not sufficient... I wasn't trying to give a complete solution, just trying to dispell any notion that interactivity with hotplug events would necessarily involve popping up a root shell on the current login users desktop :-) > Here's the sequence as I understand it: > > 1) new device gets plugged in. > 2) system has to figure out what driver to use. > 3) if it has seen it before, presumably it can consult some sort of database >to help hook it up, both by whatever driver parameters it needs, and to hook >it up to a user level program it activates. We're done at this point. > 4) if the system has never seen it before, we have to somehow ask the user >what to do. > 5) the driver finally gets loaded, with the user specified configuration >information that might be required. > 6) record the necessary driver configuration, and go to 3). > > So what we need is a convention whereby the hotplug framework activates > a GUI component talking to the user somewhere on the network to get > the configuration data required, and a way to communicate that configuration > information back to the hotplug system to record for future use (and completion > of the first hot plug event for that device). > > So the hotplug scripts (running as root) have to be able to initiate the > GUI talking to the user, and get data back from there. And it isn't > necessarily on the same system, as hotplug is not all about human interface > devices: it is also used for disk drives, tapes, etc, and eventually pluggable > processors, memory etc. > > So we have two problems: > o A convention of how to know who is administering this system. It may > be this is something just for the hotplug folks to worry about. > o How to securely get the right configuration back and forth from the user; > this is the authentication problem, in concert with how to get data back > and forth... I think it probably makes sense to reduce the communication to one of notification. - In response to the hotplug event, if the device can't be configured automatically, record that data, and notify the appropriate user(s). - When the user gets the notification, present them with the option to run a config tool, which would then complete the configuration. This has various advantages; principally. - It's flexible (notification could be sending an email saying "go to this URL to configure your new printer.) - It reduces the authentication problem to a known and solved problem. (Can user X do Y.) In terms of how to do notification, you can go from simple to complex: - Watch a file in a timeout. (We had hotplug for USB storage devices in Red Hat 7.1 working quite nicely by watching /etc/fstab for changes; kudzu added new entries in response to hotplug events. magicdev noticed the changes, signaled mc which added icons on the desktop.) - Local messaginge daemon; if you keep it simple, use unix perms, don't worry to much about quality-of-service, etc, it doesn't need to be a big project. - Networked based messaging; jabber, etc. May make sense to piggyback off an existing solution. But then you get the problem that you are talking about something big that everybody needs to adopt. Anyways, just my random thoughts on the issue. My main observation is that I think it's a mistake to think of this as "hotplug script pops up a configuration dialog" even if it might appear like that to the user in the simplest case. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
Dr Andrew C Aitchison <[EMAIL PROTECTED]> writes: > On Sat, 2 Feb 2002, Jim Gettys wrote: > > > OK, folks (both X and wm-spec-list folks, that is, that I've added to > > this thread): > > > > How do we want to solve this problem? > > > > We need a secure, interoperable way for configuration scripts running > > as root to pop up configuration GUI's on user's servers, and we need it soon > > (yesterday), as hot-plug is now a reality on Linux systems > > Are you sure you want to do this ? > Are you *absolutely* sure you want to enable this in the default installation ? > > If the root script cannot open a popup on the display, maybe it is because > the display is currently being used by someone who shouldn't have access > to the popup. > If I have a stand-alone machine, sure I want a popup when I install a new > printer/camera/player/reader in the USB/Firewire/PCMCIA socket. > However, if this is a classroom machine I might not wish to allow any user > to just plug in their device and use it. If the root script pops up a > config on their window they have just acquired more priviledges than I > wish to give them. There's no reason at all that the configuration GUI has to automatically have root privileges; I would tend to expect something along the lines of: A new device "USB Magic Camera" has been detected. Please enter the root password to configure this device: .. [ Cancel ] [ OK ] Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [I18n]Re: [Xpert]4.2 is not compatiable with 4.1 ?
Rui-Xiang Guo <[EMAIL PROTECTED]> writes: > > I believe the cause and effect was: > > > > - xcin didn't work > > - This cause untested code to be run which crashed. > > Hmm, let's go back my original question. :) > Why xcin work under XFree 4.1 but not under XFree 4.2 ? > I only wrote "setenv XMODIFIERS @im=xcin" into ~/.cshrc will cause > some programs (like gqview, mozilla,..etc) core dump without > stating up xcin. X-) xcin can be pop up but unusable. > After using your patch, I don't get core dump. > xcin still can be pop up but still unusable. Hmmm, seems to work fine for me. At least, if I start up GQView with LC_ALL=zh_TW.Big5, click in an entry and type: space a 1 space The 'sun' character is inserted, which looks plausible. This seems to indicate that xcin is at least communicating properly with Xlib. If xcin is malfunctioning at a deeper level, then it's presumably a problem within xcin, and not something I'm not really qualified to comment on. Sorry not to be of more help, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [I18n]Re: [Xpert]4.2 is not compatiable with 4.1 ?
Rui-Xiang Guo <[EMAIL PROTECTED]> writes: > On Sun, Jan 27, 2002 at 01:29:48PM -0500, Owen Taylor wrote: > > > > Owen Taylor <[EMAIL PROTECTED]> writes: > > > > > Rui-Xiang Guo <[EMAIL PROTECTED]> writes: > > > > > > OK, I was able to reproduce it and figured out the immediate > > > problem here: > > > > > > _XDynamicRegisterIMInstantiateCallback() dlopens 'ximcp.so' > > > and calls _XimRegisterIMInstantiateCallback > > > > > > _XimRegisterIMInstantiateCallback() calls lcd->methods->open_im > > > which is _XDynamicOpenIM() > > > > > > _XDynamicOpenIM() calls _XimOpenIM from ximcp.so, which fails, > > > dlcloses ximcp.so and returns control to > > > _XimRegisterInstantiateCallback() which is in a module that > > > has been unloaded, so *boom* > > > > > > The solution here is presumably to add reference counting to > > > dlopen/dlclose calls in XlcDL.c; at the same time, it would make > > > sense to fix the problem that someone apparently never > > > heard that cutting and pasting 30 lines of code over and > > > over again was a bad idea... > > > > OK, here's an attempt at doing this. > > > > a) I've done little testing on it. Xcin no longer causes > > a crash, with it. It's probably a bad idea to commit > > this without someone giving it a good look over. <> > Hi, I have tested it with your patch. Yeah, nor more core dump! > But... The xcin became unusable. I can't use it as XIM server to > input chinese. X-) > (NOTE: xcin would be run from XFree 4.1 to 4.2 without crash.) > ps: > I have read some reports about this problem, some Linux distributions > also get pain with xcin after upgrading XFree to 4.2, includes FreeBSD. > But Mandrake's users say they don't get this situation. > Maybe we need some help form them. ;) I believe the cause and effect was: - xcin didn't work - This cause untested code to be run which crashed. So, the crash was a side effect of xcin not working; I looked at it a bit and it didn't work with: XMODIFIERS=@im=xcin But it worked fine with: XMODIFIERS=@im=xcin-zh_TW (At least, I got a status window to pop up.) If the previous used to work, it probably was because Xlib used to be less strict about checking the IM server name; xcin doesn't seem to support 'xcin' as a servername, just xcin-zh_TW and xcin-zh_CN. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Transparent color problem
[EMAIL PROTECTED] writes: > Hi, Please HELP! > > I'm using Linux RedHat 7.1 with XFree86 4.1.0 as X-terminal connected to > Sun Solaris. > > I have a problem with transparent color on applcation's items: > > I got magenta color exept of transparent one. > > Platform: Intel > Video Card ATI Mach64 8MByte > > What is the problem: overlays or colors definition? You'll probably need to tell us more about what applications you are using and what they are doing for someone to provide a useful response. I would be surprised if the Mach64 even supported overlays, so this sounds more like some sort of application problem. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [I18n]Re: [Xpert]4.2 is not compatiable with 4.1 ?
It seems that imConv.c is currently linked into libX11.so. Is it also necessary to link it into ximcp.so? I wouldn't have thought so. In any case, this doesn't look related to this particular problem. Regards, Owen ISHIKAWA Mutsumi <[EMAIL PROTECTED]> writes: > Hi, > > > In <[EMAIL PROTECTED]> > > Rui-Xiang Guo <[EMAIL PROTECTED]> wrote: > >> Hi, all > >> recently I update my XFree 4.1 to 4.2 and find some programs > >> no more work. :( > >> Like gqview, mozilla,...etc, which compiled with gtk/glib just > >> get the core dump. > > >> I use XFree 4.2 on NetBSD/i386. > >> Does other platforms also get this situation? > > Will this patch fix the problem ? > > --- xc/lib/X11/xlibi18n/im/ximcp/Imakefile.orig Sun Jan 27 20:50:51 2002 > +++ xc/lib/X11/xlibi18n/im/ximcp/ImakefileSun Jan 27 20:51:43 2002 > @@ -1,7 +1,7 @@ > #include "../../Xi18nLib.conf" > > EXTRA_INCLUDES = -I../../.. > - SRCS = imCallbk.c imDefFlt.c imDefIc.c \ > + SRCS = imCallbk.c imConv.c imDefFlt.c imDefIc.c \ > imDefIm.c imDefLkup.c imDispch.c imEvToWire.c \ > imExten.c imImSw.c imInsClbk.c imInt.c \ > imLcFlt.c imLcGIc.c imLcIc.c imLcIm.c imLcLkup.c \ > @@ -16,6 +16,7 @@ > REQUIREDLIBS = -L$(XENVLIBDIR) -lX11 -lc > > LinkSourceFile(imCallbk.c, ../../..) > +LinkSourceFile(imConv.c, ../../..) > LinkSourceFile(imDefFlt.c, ../../..) > LinkSourceFile(imDefIc.c, ../../..) > LinkSourceFile(imDefIm.c, ../../..) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [I18n]Re: [Xpert]4.2 is not compatiable with 4.1 ?
Owen Taylor <[EMAIL PROTECTED]> writes:
> Rui-Xiang Guo <[EMAIL PROTECTED]> writes:
>
> OK, I was able to reproduce it and figured out the immediate
> problem here:
>
> _XDynamicRegisterIMInstantiateCallback() dlopens 'ximcp.so'
> and calls _XimRegisterIMInstantiateCallback
>
> _XimRegisterIMInstantiateCallback() calls lcd->methods->open_im
> which is _XDynamicOpenIM()
>
> _XDynamicOpenIM() calls _XimOpenIM from ximcp.so, which fails,
> dlcloses ximcp.so and returns control to
> _XimRegisterInstantiateCallback() which is in a module that
> has been unloaded, so *boom*
>
> The solution here is presumably to add reference counting to
> dlopen/dlclose calls in XlcDL.c; at the same time, it would make
> sense to fix the problem that someone apparently never
> heard that cutting and pasting 30 lines of code over and
> over again was a bad idea...
OK, here's an attempt at doing this.
a) I've done little testing on it. Xcin no longer causes
a crash, with it. It's probably a bad idea to commit
this without someone giving it a good look over.
b) I'm not entirely happy with the patch since it leaks
reference counts; as I say in a comment:
/* We reference count dlopen() and dlclose() of modules; unfortunately,
* since XCloseIM, XCloseOM, XlcClose aren't wrapped, but directly
* call the close method of the object, we leak a reference count every
* time we open then close a module. Fixing this would require
* either creating proxy objects or hooks for close_im/close_om
* in XLCd
*/
While this probably isn't harmful in practice, it's
certainly ugly. If one of these fixes isn't done,
it might be cleanest to add a 'permanently_loaded'
flag to keep the reference count flag from increasing
indefinitely.
Regards,
Owen
Index: XlcDL.c
===
RCS file: /cvs/xc/lib/X11/XlcDL.c,v
retrieving revision 1.5
diff -u -p -r1.5 XlcDL.c
--- XlcDL.c 2002/01/23 16:26:41 1.5
+++ XlcDL.c 2002/01/27 18:20:48
@@ -83,6 +83,7 @@ typedef struct {
char *im_register;
char *im_unregister;
int dl_release;
+ unsigned int refcount;
#if defined(hpux)
shl_t dl_module;
#else
@@ -214,6 +215,7 @@ Limit the length of path to prevent stac
xi18n_objects_list[lc_count].open = strdup(args[2]);
xi18n_objects_list[lc_count].dl_release = XI18N_DLREL;
xi18n_objects_list[lc_count].locale_name = strdup(lc_name);
+ xi18n_objects_list[lc_count].refcount = 0;
xi18n_objects_list[lc_count].dl_module = (void*)NULL;
if (n == 5) {
xi18n_objects_list[lc_count].im_register = strdup(args[3]);
@@ -284,6 +286,85 @@ const char *lc_dir;
return path;
}
+/* We reference count dlopen() and dlclose() of modules; unfortunately,
+ * since XCloseIM, XCloseOM, XlcClose aren't wrapped, but directly
+ * call the close method of the object, we leak a reference count every
+ * time we open then close a module. Fixing this would require
+ * either creating proxy objects or hooks for close_im/close_om
+ * in XLCd
+ */
+static Bool
+open_object (object, lc_dir)
+ XI18NObjectsList object;
+ char *lc_dir;
+{
+ char *path;
+
+ if (object->refcount == 0) {
+ path = __lc_path(object->dl_name, lc_dir);
+#if defined(hpux)
+ object->dl_module = shl_load(path, BIND_DEFERRED, 0L);
+#else
+ object->dl_module = dlopen(path, RTLD_LAZY);
+#endif
+ Xfree(path);
+
+ if (!object->dl_module)
+ return False;
+}
+
+ object->refcount++;
+ return True;
+}
+
+static void *
+fetch_symbol (object, symbol)
+ XI18NObjectsList object;
+ char *symbol;
+{
+void *result = NULL;
+#if defined(hpux)
+int getsyms_cnt, i;
+struct shl_symbol *symbols;
+#endif
+
+#if defined(hpux)
+getsyms_cnt = shl_getsymbols(object->dl_module, TYPE_PROCEDURE,
+ EXPORT_SYMBOLS, malloc, &symbols);
+
+for(i=0; i 0) {
+free(symbols);
+}
+#else
+result = (XLCd(*)())try_both_dlsym(object->dl_module, symbol);
+#endif
+
+return result;
+}
+
+static void
+close_object (object)
+ XI18NObjectsList object;
+{
+ object->refcount--;
+ if (object->refcount == 0)
+{
+#if defined(hpux)
+shl_unload(object->dl_module);
+#else
+dlclose(object->dl_module);
+#endif
+object->dl_module = NULL;
+}
+}
+
XLCd
#if NeedFunctionPrototypes
_XlcDynamicLoad(const char *lc_name)
@@ -294,14 +375,9 @@ _XlcDynamicLoad(lc_name)
{
XLCd lcd = (XLCd)NULL;
XLCd (*lc_loader)() = (XLCd(*)())NULL;
-char *path;
int count;
XI18NObjectsList objects_list;
char lc_dir[BUFSIZE];
-#if defined(hpux)
-int getsyms_cnt, i;
-struct shl_symbol *symbols;
-#endif
if (lc_name == NULL) return (XLCd)NULL;
@@ -315,45 +39
Re: [Xpert]4.2 is not compatiable with 4.1 ?
Rui-Xiang Guo <[EMAIL PROTECTED]> writes: > > What input method are you using? I've seen another report of this for > > Chinese (http://bugzilla.gnome.org/show_bug.cgi?id=69523); but > > it seems to work fine for Japanese (or at least, no reports of > > problems.) > > Hello, > I use xcin as chinese input method. Yes, this is the problem causes > core dump. After I remove this line "setenv XMODIFIERS @im=xcin" > from ~/.cshrc file, everything works fine. OK, I was able to reproduce it and figured out the immediate problem here: _XDynamicRegisterIMInstantiateCallback() dlopens 'ximcp.so' and calls _XimRegisterIMInstantiateCallback _XimRegisterIMInstantiateCallback() calls lcd->methods->open_im which is _XDynamicOpenIM() _XDynamicOpenIM() calls _XimOpenIM from ximcp.so, which fails, dlcloses ximcp.so and returns control to _XimRegisterInstantiateCallback() which is in a module that has been unloaded, so *boom* The solution here is presumably to add reference counting to dlopen/dlclose calls in XlcDL.c; at the same time, it would make sense to fix the problem that someone apparently never heard that cutting and pasting 30 lines of code over and over again was a bad idea... Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2 is not compatiable with 4.1 ?
Rui-Xiang Guo <[EMAIL PROTECTED]> writes: > Hi, all > recently I update my XFree 4.1 to 4.2 and find some programs > no more work. :( > Like gqview, mozilla,...etc, which compiled with gtk/glib just > get the core dump. > It seems to the problem of X11 lib. > Here are some gdb message from gqview: > ... > Reading symbols from /usr/pkg/lib/libjpeg.so.62...done. > Loaded symbols for /usr/pkg/lib/libjpeg.so.62 > Reading symbols from /usr/pkg/lib/libpng.so.2...done. > Loaded symbols for /usr/pkg/lib/libpng.so.2 > Reading symbols from /usr/lib/libz.so.0...done. > Loaded symbols for /usr/lib/libz.so.0 > Reading symbols from /usr/lib/libc.so.12...done. > Loaded symbols for /usr/lib/libc.so.12 > Reading symbols from /usr/X11R6/lib/X11/locale/common/xlcDef.so.2...done. > Loaded symbols for /usr/X11R6/lib/X11/locale/common/xlcDef.so.2 > #0 0x4846f467 in ?? () > (gdb) bt > #0 0x4846f467 in ?? () > #1 0x482ad089 in _XDynamicRegisterIMInstantiateCallback () >from /usr/X11R6/lib/libX11.so.6 > #2 0x482930a7 in XRegisterIMInstantiateCallback () >from /usr/X11R6/lib/libX11.so.6 > #3 0x481facae in gdk_im_open () from /usr/X11R6/lib/libgdk.so.12 > #4 0x481eb4e7 in gdk_init_check () from /usr/X11R6/lib/libgdk.so.12 > #5 0x48149036 in gtk_init_check () from /usr/X11R6/lib/libgtk.so.12 > #6 0x481494a5 in gtk_init () from /usr/X11R6/lib/libgtk.so.12 > #7 0x806bd38 in ?? () > #8 0x804edc0 in ?? () > (gdb) > > I use XFree 4.2 on NetBSD/i386. > Does other platforms also get this situation? What input method are you using? I've seen another report of this for Chinese (http://bugzilla.gnome.org/show_bug.cgi?id=69523); but it seems to work fine for Japanese (or at least, no reports of problems.) Were input methods working correctly before the upgrade? (This seems to be a segfault on the "failed to open input method" path.) Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]MGASetupForCPUToScreenTexture() inefficiency
[ I originally sent this to [EMAIL PROTECTED], but it's really
more of a driver topic than a RENDER topic, probably this is
a better place; I apologize for the duplication. ]
Testing out my rendering code, I noticed that I wasn't getting the
speedups I expected with HW compositing on the MGA. Looking into this,
I discoved that MGASetupForCPUToScreenTexture() copied the entire
source drawable into video memory every time. Since the way that GTK+
works is to use a different bit of one large source drawable for every
operation, this causing just a bit of a slowdown.
Here's a patch that fixes this problem by simply allocating the
scratch area in MGASetupForCPUToScreenTexture() and then doing the
copies in MGASubsequentCPUToScreenTexture().
Since this is not an area that I'm very familiar with, I'd appreciate
if someone would look this over - in particular, the way I'm passing
a bunch of parameters from MGASetupForCPUToScreen*Texture() to
MGASubsequentCPUToScreenTexture() using a bunch of static variables
seems ugly, but that was how it was done for tex_padh/padw so I
copied that.
The other reason I have some trepidation about this patch is that
things are not really working for me correctly now - the general
symptom is that the alpha channel is correct but everything appears as
black. (But the right data seems to be fed to the card.) I had this
symptom with XFree86-4.1, upgraded to 4.2, seemed to go away, made my
patch, seemed to work fine, then at some point it stopped working
so it possibly is some sort of unitialized register problem.
Regards,
Owen
? Makefile
? mga.4.html
? mga._man
Index: mga_storm.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_storm.c,v
retrieving revision 1.96
diff -u -p -r1.96 mga_storm.c
--- mga_storm.c 2001/12/06 15:54:52 1.96
+++ mga_storm.c 2002/01/08 03:05:40
@@ -282,6 +282,10 @@ GetPowerOfTwo(int w)
static int tex_padw, tex_padh;
+static CARD8 *tex_mem;
+static int tex_mem_pitch;
+static int tex_scratch_pitch;
+static int tex_bytes_per_pixel;
Bool
MGASetupForCPUToScreenAlphaTextureFaked (
@@ -379,7 +383,6 @@ MGASetupForCPUToScreenAlphaTexture (
int flags
){
int log2w, log2h, i, pitch, sizeNeeded, offset;
-CARD8 *dst;
MGAPtr pMga = MGAPTR(pScrn);
if(op != PictOpOver) /* only one tested */
@@ -415,13 +418,12 @@ MGASetupForCPUToScreenAlphaTexture (
MGAStormSync(pScrn);
i = height;
-dst = pMga->FbStart + offset;
-while(i--) {
- memcpy(dst, alphaPtr, width);
- dst += pitch;
- alphaPtr += alphaPitch;
-}
-
+
+tex_mem = alphaPtr;
+tex_mem_pitch = alphaPitch;
+tex_scratch_pitch = pitch;
+tex_bytes_per_pixel = 1;
+
tex_padw = 1 << log2w;
tex_padh = 1 << log2h;
@@ -502,6 +504,11 @@ MGASetupForCPUToScreenTexture (
if(!AllocateLinear(pScrn, sizeNeeded))
return FALSE;
+tex_mem = texPtr;
+tex_mem_pitch = texPitch;
+tex_scratch_pitch = pitch << 2;
+tex_bytes_per_pixel = 4;
+
offset = pMga->LinearScratch->offset << 1;
if(pScrn->bitsPerPixel == 32)
offset <<= 1;
@@ -509,16 +516,6 @@ MGASetupForCPUToScreenTexture (
if(pMga->AccelInfoRec->NeedToSync)
MGAStormSync(pScrn);
-{
- CARD8 *dst = (CARD8*)(pMga->FbStart + offset);
- i = height;
- while(i--) {
-memcpy(dst, texPtr, width << 2);
- texPtr += texPitch;
- dst += pitch << 2;
- }
-}
-
tex_padw = 1 << log2w;
tex_padh = 1 << log2h;
@@ -553,7 +550,22 @@ MGASubsequentCPUToScreenTexture (
int width,
int height
){
+int i, offset;
MGAPtr pMga = MGAPTR(pScrn);
+CARD8 *texPtr = tex_mem + srcy * tex_mem_pitch + (srcx << 2);
+CARD8 *dst;
+
+offset = pMga->LinearScratch->offset << 1;
+if(pScrn->bitsPerPixel == 32)
+offset <<= 1;
+
+dst = (CARD8*)(pMga->FbStart + offset) + srcy * tex_scratch_pitch + (srcx << 2);
+i = height;
+while(i--) {
+memcpy(dst, texPtr, width * tex_bytes_per_pixel);
+texPtr += tex_mem_pitch;
+dst += tex_scratch_pitch;
+}
WAITFIFO(4);
OUTREG(MGAREG_TMR6, (srcx << 20) / tex_padw);
Re: [Xpert]Best 2D-only card for X11
Ross Vandegrift <[EMAIL PROTECTED]> writes: > > > Matrox is the only company I've ever heard make noise about their 2D > > > performance. The box from my G400 DualHead billed it as the fastest > > > 2D accelerator ever created. Don't know if it's true, but the 2D > > > performs quite well for me! > > > > The mga driver has a very good reputation for 2D performance, but I just > > replaced a G450 with a Rage128 Pro in this work machine and it's at > > least as fast in general, in fact it feels slightly snappier, but maybe > > that's just me. :) A Radeon should be significantly faster in turn. The > > only thing lacking yet is Render acceleration for AA text. I'm > > experimenting with that but no dice yet. > > Hmmm, that's really interesting. Maybe I'll have to see if I can find > some ATI cards and do a comparison. Is it most likely the hardware and > not the drivers? I'm also mostly interested in fast 2D performance from > a card. > > (A friend of mine has a Rage 128 Pro. Maybe I'll see if I could borrow > it and do some benchmarks) Most 2D operations (blits, area fills, etc) are "infinitely fast" these days for all practical purposes on modern cards with a driver that can accelerate the basic operations. Performance has to do with: - Usage of video RAM. - Acceleration of RENDER extension if that is in use - Bus bandwidth. (speed of getting data to and from the card matters.) Only the 3rd has any significant dependence on hardware alone; the first is a function of the XFree86 core code mostly, combined with the amount of video RAM available, the second is mostly a driver issue, though speed does depend on the card; of the two I've tested with hw accel, the G400 is darn fast, the nvidia binary drivers are a lot faster yet. I like the Matrox cards because they produce high quality output, are pretty well accelerated, and have docs available to the community; but in terms of pure speed, even for 2D operations, they probably lag recent ATI and nvidia cards. ATI also does pretty well on the quality and OSS areas, and if you have any interest in 3D, their cards are a better bet. (Though the Matrox cards work fine for Quake3 level-games.) In the end, 2D performance shouldn't be much of an issue for users on any decently supported video card these days. The exceptions to this are typically application, toolkit, server, or driver problems, not HW limitations. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Font + antialiasing fsckes up certain characters
Richard =?utf-8?B?xIxlcGFz?= <[EMAIL PROTECTED]> writes: > On Sun Dec 16 11:39:05 2001 +0200 Richard Čepas wrote: > > >On Sat Dec 15 18:40:02 2001 -0800 Keith Packard wrote: > > > >> > >>Around 23 o'clock on Dec 15, Peter Surda wrote: > >> > >>>Well, konqueror is using Qt, isn't it? So this is actually a Qt bug? I have no > >>>idea, that's why I'm asking... I have RH 7.2 with almost all updates > >>>(qt-2.3.1-5)... > >> > >> Yes, all of KDE is based on Qt, konqueror included. Sounds like a > >> Qt bug of some kind; they may be mis-converting from Latin-2 to > >> Unicode. > >> > >I have also noticed this effect (try konsole for example). I > > don't use latin2 but utf-8. It happens with Type1fonts from > > XFree 4.1 like Courier or Lucidux*. It doesn't happen with TTF. > > > > ... and it shows with xterm as well, so it is probably XFree bug: > xterm -fa 'Courier New' -fs 14 > is OK, but this: > xterm -fa LuciduxMono -fs 14 > shows space instead č. You can cut&paste it, i.e. character code is OK, but it >just shows as blank. > -- To quote from the freetype CVS logs: 2001-10-08 davidT * /cvsroot/freetype2/src/psnames/psmodule.c, /cvsroot/freetype2/src/psnames/pstables.h: * src/psnames/pstables.h, src/psnames/psmodule.c, src/tools/glnames.py: fixed a bug in 'glnames.py' that prevented it from generating correct glyph names table. This resulted in the unavailability of certain glyphs like "Cacute", "cacute" and "lslash" in Unicode charmaps, even if these were present in the font (causing problems for Polish users). You might want to try upgrading to FreeType 2.0.5 - it most likely contains this fix. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XCheck*Event() equivalent to select() ?
Jonathan Walther <[EMAIL PROTECTED]> writes:
> For reasons to do with a user interface element I'm working on,
> I need something like select. Do the XCheck*Event() functions
> block? I'm really reluctant to use pthreads, as this isn't portable
> enough for what I'm trying to do.
>
> Specifically, if the app is in a certain state, I want to update the
> window every 1/32 of a second, but I need to keep processing events too.
> If XCheckWindowEvent() doesn't block, and is reasonably quick, it will
> do perfectly. Does it?
The standard way of doing a non-blocking check is
if (XPending (display))
{
XNextEvent (display, &event);
}
Using any of the XCheck*Event functions can be relatively slow, since
they need to search the entire queue. (If you had to use one, I'd
suggest using XCheckIfEvent with an appropriate predicate. But XPending()
should be as good or better.)
Of course, what real toolkits do is select() on ConnectionNumber(display)
to know when they need to call XPending() without having to poll
continuously.
Regards,
Owen
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]popup windows
Derrik Pates <[EMAIL PROTECTED]> writes:
> On Tue, 4 Dec 2001, Daniel Secrieru wrote:
>
> > They don't have a title bar.
>
> And that's why there are WM hints, so you can tell the WM "hey, don't
> decorate me!"
For transient popups like menus, the correct thing to do is to set the
window "override redirect" (option in XWindowAttributes); as long
as you have the pointer grabbed, this works fine.
For undecorated windows that stick around, you need to use window
manager hints - the ICCCM doesn't have anything in this line, but
there are:
- The motif window manager hints which include control over
decorations (never documented, but you can find code using
them in a lot of places)
- The Extended window manager hint spec (http://www.freedesktop.org/standards/)
which includes semantic hints that typically produce undecorated
windows. ("I am a tearoff toolbar")
Regards
Owen
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xnest under Xinerama
George Staikos <[EMAIL PROTECTED]> writes: > Is there a way to keep Xnest from using a desktop size with roughly the same > aspect ratio as the parent desktop when run under Xinerama? Whenever I > launch it (and I couldn't find appropriate parameters... -xinerama did > nothing), it is as elongated as the entire xinerama desktop which is not very 'man xnest', look at the -geometry argument. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 2D accel very slow when DRI is enabled.
It's a little suprising to me that removing some (fairly unimportant) accelerations makes 2D "painfully slow"; except for a few things like blits and solid area fills, acceleration just doesn't matter much any more. What applications were you testing with? I've seen DRI slow 2D down to a "crawl", but that's only been in memory limited situations where there isn't enough remaining offscreen memory for pixmaps, so drawing to them isn't accelerated at all. (Not even CopyArea and solid fills.) >From the diff, it looks like you probably have a 64mb card, so I doubt that is the case for you. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]minmax events
"Daniel Secrieru" <[EMAIL PROTECTED]> writes: > > When window managers iconize and deiconize windows they usually > > just unmap and map them. See the man page on XMapEvent. > Well, when minimizing/maximizing, the window doesn't neccesarily > disappear/appear (that's what unmap/map events mean, right?), it usually > just shrinks to a minimum size/grows to a maximum size. The older ICCCM does not contain an idea of maximization, but the extended window manager hints spec - http://www.freedesktop.org/wm-spec.html does contain this concept and many window manager now support the extended hints. You'd want to watch from PropertyNotify events on your toplevel for the _NET_WM_STATE property. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]pointer/mouse
"Daniel Secrieru" <[EMAIL PROTECTED]> writes: > >The root window isn't just another window. It's the root > > window - the desktop. > I'm sorry, but I still don't understand. If I have an one-window > application, that makes sense: the root of the only window is of course the > desktop. > But what if I have an multi-windowed application, with dialog windows > and stuff? The root of a dialog windows is going to be another window and > not the desktop. And then what's the point, for XQueryPointer(...) to return > in the argument 'root_return' the root of the window (the 'w' argument) the > pointer is in, if that is always the desktop? Because on displays with multiple screens (independent, not merged with Xinerama), each screen has a different root window. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RedHat keeps installing 3.3.6a
"David Epelboim" <[EMAIL PROTECTED]> writes: > I'm running Red Hat 7.2 and it installs XFree86 3.3.6a and > apparently 4.1.0 too but I cannot run 4.1.0, I have tried customs > installs and it keeps installing 3.3.6a > > Does anyone knows how can I force it to install 4.1.0 or how can I > make it run in 4.1.0 if it is already installed? (the GnoRPM shows > 4.1.0 package installed) I very much doubt you _don't_ have XFree86-4.1.0 installed. Running 'rpm -q XFree86'. Will show you the version of your main XFree86. We do ship the XFree86-3.3.6 servers as well, since there are some old graphics cards that are still not supported well by XFree86-4.1.x. The only reason that the installer or XConfigurator would be setting up an XFree86-3.3.6 server for you would be if you had such a card. You may be able to force the issue with: Xconfigurator --preferxf4 Which tells it to use the 4.1.0 server even if it doesn't think it will work as well as the 3.3.6 server. Regards, Owen [ Are you sure that it is running 3.3.6? `xdpyinfo` is the best way of figuring out what is running - you should see a line like 'XFree86 Version: 4.1.0' ] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xkb+grabbing+intl. keyboard: mode_switch does not work?
Alexander Zangerl <[EMAIL PROTECTED]> writes: > i'm running 3.3.6, and was up to now using xkb for my german keyboard. > > the problem i've encountered is: > programs like xscreensaver, quintuple-agent etc. that are grabbing > the keyboard for passphrase input cannot receive input that is generated > using mode_switch+key, eg. @ (mode_switch+q). > > i've digged into both apps and added ugly printf debugging, and that > is what i detected: there are two events generated, one for the > keypress of altgr and one for q. XLookupString returns no string for > the first event, which is ok as altgr/mode_switch is nonprintable and > just a modifier. unfortunately, XLookupString does then return just q > for the second event, which is wrong. > > all other x apps like xev that do not grab the keyboard work fine. > everything works fine, if i switch off xkb totally. > > my xkb setup is absolutely plain, model pc102, layout de, > variant nodeadkeys and options ctrl:nocaps. > > i went through the list archive, but i have not found anything > that seems to be related to that problem. > > my question now is: is this a known problem? if so, how likely > is a fix for this? I've seen reports of this this problem from other people (don't remember at this point whether it was a mozilla bug report, a GTK+ bug report, a Red Hat bug report, but I remember seeing something.) I'm pretty sure this was fixed as of 4.0.x. So, you might want to try updating to something recent. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Copying/Pasting
Sunny Dubey <[EMAIL PROTECTED]> writes: > hi > > How do I disable the ability to copy to the clip board buffer by > highlighting? As much as I love Xfree86, and thank the amazing guys who > write code for stupid people like me, this one feature makes me want to pull > my hair out. I know that various applications like Koffice and Star Office > have the ability to disable this feature (locally within their own domains) > however, I'd like to know if disabling this feature globally under X. > Anyone have any ideas? > > (Sorry if this was the wrong mailing list for this post) Please read: http://www.freedesktop.org/standards/clipboard.txt While it may not answer your question, it should at least give you useful background in what is going on. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]running displays
Nico Galoppo <[EMAIL PROTECTED]> writes: > --* Owen Taylor (Wed, Oct 03, 2001 at 08:36:24AM -0400) *-- > > > You can find out what display/server applications are using by > > printing the DISPLAY environment variable: > > > > echo $DISPLAY > > Sorry, I think i misexpressed myself. I'd like to know what display the > X server is listening on. A server running on DISPLAY will typically: - listen on the TCP port 6000 + - listen on the Unix domain socket /tmp/.X11-unix/X (It could also be listening on DECNET, OS/2 pipes, etc... IPv6 support is likely to become standard at some point in the future.) So, by using a command such as 'lsof' it's possible to figure out what displays a server is listening on. There is (AFAIK) no way to find this out through the X protocol, because a server may be available by many names. A display name is a way of contacting a display. A single display may well be available as: :0 - local unix domain socket localhost:0 - Over TCP :10.0 - forwarded over ssh > Eg. ssh sets $DISPLAY to > myhost.domain.org:10.0, while that doesn't work if the Xserver is Note that ssh acts as a proxy server, so myhost.domain.org:10.0 will typically be forwarded through to your real display. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]running displays
the main scenic man <[EMAIL PROTECTED]> writes: > Hi, > > I'd like to know if there's a way to determine the display a running X > server is connected to, eg. whether it is localhost:0.0 or > remotename:0.0. This question doesn't make much sense to me. The X server _is_ the display - it isn't connected to a display. (Ignoring the unusual case of proxy servers.) You can find out what display/server applications are using by printing the DISPLAY environment variable: echo $DISPLAY Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problem with SGI 1600SW and Number Nine Revolution IV
Alan Schmitz <[EMAIL PROTECTED]> writes: > On Sun, 16 Sep 2001, John A Chaves wrote: > > > Alan Schmitz wrote: > > > > > > > > I can reliably bring up GDM when the computer first boots to run-level 5, > > > and I can reliably login to a single X session. If I try to reboot the > > > computer from within GNOME, it will lock-up hard as soon it's supposed to > > > switch to a text mode console. Logging out of my X session will lock the > > > system up hard about 50% of the time on the way back to GDM. The system > > > behaves the same way, if I switch to XDM. > > > > > > If I boot to run-level 3 and use "startx" to start my X session, I don't > > > have any problems rebooting or logging in, starting X, and stopping X > > > repeatedly. While I can continue to operate this way, I'd really rather > > > run with a display manager like GDM. > > > > > > Is there something I can do to GDM, XDM, or the X server itself to keep > > > them from crashing the system? > > > > This happens when the Xserver is asked to reset itself after a user session. > > A workaround is to kill the Xserver instead, forcing a new one to be loaded. > > For at least xdm and kdm, this can be done by setting > > > > DisplayManager*resetSignal: 15 > > > > in the appropriate X environment (/etc/X11/xdm/xdm-config I think). > > Thanks, that fixed xdm. I'll keep looking for a similar option for gdm. Run gdmconfig. "Expert" Options, "X-server setup" tab, "Always restart X servers" checkbox. Yes, GDM has _far_ too many options. :-) Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]G450 2d acceleration at 24bit problems
[EMAIL PROTECTED] writes: > On 4 Sep, Dr Andrew C Aitchison wrote: > > On Mon, 3 Sep 2001, Robert A. Knop Jr. wrote: > > > >> > >> Sadness. And here was me thinking that 32MB was a lot of video RAM. > >> (Indeed, doing the math, it would seem that only 8MB should be necessary > >> to display a 4-byte deep screen at 1600x1200... which should leave > >> plenty of memory left over for off-screen buffers and 3d buffers and > >> such. What's up here?) > > > > The code in mga_storm.c is trying to grab as much memory for textures as > > possible (the author seems to value 3D performance above anything else). > > I'm not convinced that it isn't grabing a little too much. > > This problem is not unique to mga. It is a common problem. I have > noticed that if I build with DRI enabled many drivers promptly consume > most of the video ram for 3D work. This is annoying but understandable. > They are optimizing for 3D performance because it is important to many > people. > > But in my case, I want lots of available space for pixrects. I do > mostly 2D image work, with the occasional 3D activity. Keeping lots of > pixrects in video ram definitely improves window manager manipulations > and pan operations. > > A compile time solution does exist. I can rebuild X without DRI and only > suffer the somewhat excessive pixrect consumption from XAA. (It gets too > enthusiastic about texture caching when it sees all that empty video > ram.) I might go look at the XAA algorithm to see whether it is easy to > put some bounds on it. > These are not reasonable for the bulk of users who want to use > pre-compiled X server and module from some distribution. Perhaps we > should look at some X startup options instead of compile time options > for this code. This would then enable the mode that would best match > what I do: an X server that uses software 3D even on hardware capable of > hardware 3D via DRI. The gaming and other 3D users would consider this > totally absurd. I don't need frames per second because I am generating > scenes and manipulating 2D images. Well, you certainly don't have to recompile to turn off DRI, just turn off the options in your XF86Config. To get a command line option, you could use the -xf86config option to XFree86 and switch between two config files. I'd agree that the gobble-most-ram-for-3D is detrimental for people doing only 2D. The pretty clear long term right solution is to dynamically adjust the allocation of video ram when a 3D client is started, but I would suppose that to be a moderately ambitious project. Regards, Owen (I've also noticed that on my 32Meg G400, a lot more ram is being used for the tile/stipple cache than seems justified, at 16bpp, it allocates 32 128x128 tiles, 32 256x256 tiles, 16 512x512 tiles... I can't really conceive of an app that would continually paint with that many different titles/stipples at once. So some static improvements in memory allocation may also be possible) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
