[Xpert]Locked Mouse and/or Keyboard
Is there a way to get the keyboard or mouse back from a frozen application? I've looked around and haven't been able to find any information about this. It would seem that when an Xclient freezes up and needs to be killed, there could be some way to get the keyboard and mouse to unlock -- perhaps with an optional keybinding or something like that? It would be very handy to not have to kill X to get the keyboard back when the only thing frozen is gaim or something similar... -Albert I believe in death after life... "Someone has to be screwed up to teach everyone else" PGP Key and Fingerprint: http://www.cs.washington.edu/homes/awong/gnupgpkey.txt 603F 118F 2B0E 47C6 9FCE B0AA DA83 089D B120 6714 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert](no subject)
Ling ChenTvia,Inc.Hefei office Software department.
Re: [Xpert]Xinerama api
On Sat, 15 Dec 2001, Bj|rn Englund wrote: > First of all, is there any documentation for Xinerama except > the Xinerama.h file? Pretty much. > > From what I've seen there is no way to get the > physical size of the monitors that are used for the different > screens in Xinerama. Is this true? If so, will it > be fixed/added? I thought it was pretty obvious how to do that from the description in Xinerama.h. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Font + antialiasing fsckes up certain characters
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. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fourcc Codes
On Sat, 15 Dec 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > > > The "fourcc.h" file does not contain any RGB formats. Is there any > > > particular reason for this??http://www.webartz.com/fourcc has > > > standard RGB formats defined as well. Why not include them for the > > > next release. > > > > I don't think any drivers are using RGB formats. Also, there aren't > > unambiguous fourcc codes for RGB as far as I can tell. > > Need to start somewhere to encourage driver writers to support RGB > overlay surfaces. Why don't we start by standardizing what X uses for > RGB fourccs. > > Unfortunately in the Windows world, you construct a 565 overlay by > using the RGB bitfield fourcc and setting some other parameter to ask > for 565, from what I remember. Yes, which means that a single fourcc describes many different formats. If we had to standardize on something it would probably be 8 bit per component formats. Also, Microsoft registers all of theirs with backwards names from the rest of the industry. It's standard to name them from LSB to MSB (all the YUV formats are that way) but Microsoft does it the other way around. If I were to hack something up I would do "BGRA" which is an 8:8:8:8 ARGB format "BGRX" which is the same but without alpha. And probably "BGR " for a 24 bpp packed format. Most people can do these with their texture engines. I wouldn't bother filling in the GUID field, because these are a hack and the guid isn't valid. I expect that this could be done faster than with drawpixels in OpenGL for the most part, because the pipeline is much simpler than draw pixels. I'm reluctant to put those in fourcc.h because they're not official. All the "official" ones registered by Microsoft are confused and ambiguous. If anyone knows of some non-fucked-up RGB formats registered someplace, I'd like to know about them. We'll use those instead. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Font + antialiasing fsckes up certain characters
On Sat, Dec 15, 2001 at 02:01:51PM -0800, Keith Packard wrote: > Around 20 o'clock on Dec 15, Peter Surda wrote: > > I have a question about fonts. When using antialiased fonts, the character > > c+caret (that's what I think it's called, it's used in several Slavic Central > > European languages and is of course in iso-8859-2) doesn't get displayed, > Anti-aliased fonts are always in Unicode; your application may not be > correct translating from the Latin-2 encoding to Unicode. You might give > this a try with a Qt application and see if it works right. 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)... > Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. msg02506/pgp0.pgp Description: PGP signature
Re:[xpert]Fourcc Codes
> > I don't think any drivers are using RGB formats. Also, there aren't >unambiguous fourcc codes for RGB as far as I can tell. > > > Mark. > Current drivers do not use RGB but it might be helpful for future development. Many people (including me and on this list as well) would like to see RGB scaling ability in Xv. Also permedia 3 driver (pm3_video.c) has many RGB formats as well for overlay. Pranay _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
On Sun, 16 Dec 2001, Bj|rn Englund wrote: > Sat Dec 15 2001, Mark Vojkovich wrote: > > > >So, it's going to change at sometime when there's an official > > API. XFree86 will be backwards compatible with the old > > protocol but the sample implementation and all the commercial > > vendors won't acknowledge the current protocol. You just have > > to keep that in mind, and you'll be expected to rewrite all > > your Xinerama awareness code at some point if you want it to > > work with anything other than XFree86. The current solution > > was a hack to keep the Enlightenment guys happy. > > I understand that things will have to be rewritten when there > is an official standard. But since many progams/people uses > Xinerama as it is now, would it be possible to add this feature > (physical size) to the existing non official API or > do you expect an official API soon? > Or should I just use an external config file where the user > can specifiy the sizes of the screens for the time > until the official API ? > I understand if you don't have the time to do this, but do you > think it would be a good idea? > At least this possibility should be in the official version. It's not in the drafts of the official version. This has never been considered at all as far as I can tell. Is the size of the screen actually useful? DPI seems more useful, but even that doesn't make sense with XFree86's virtual desktops. > > I have another question about Xinerama too. > Is it possible to have several resolutions configured and switch > with <+/-> on individual screens or all together or > not at all when Xinerama is enabled? It's the same as normal multihead. The resolutions change on the individual screens but the portion of the desktop that they can view (via desktop panning) does not. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
Sat Dec 15 2001, Mark Vojkovich wrote: >Is the size of the screen actually useful? DPI seems more > useful, but even that doesn't make sense with XFree86's virtual > desktops. > DPI or size is ok, easy to convert between if one has the resolution. Important that one get separate DPI for X and Y though. It's very useful when you wan't fullscreen video with correct aspect on a screen. In non multihead configurations we use the XF86VidMode at the moment to get the resolution (works when the user has <+/->'ed), where the normal X11 call "fails" (just reports the total area). /Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
> Is the size of the screen actually useful? DPI seems more useful, but > even that doesn't make sense with XFree86's virtual desktops. We just need the pixel aspect ratio to calculate correct scaling for video or any digital image. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI Mobility Radeon 7500?
Hi, Am in the process of buying a Dell i8100 in NZ. In the US there is a choice betwen | NVIDIA® GeForce2 Go video controller with choice of 16 or 32 MB | of DDR SDRAM | ATI Mobility Radeon 7500 video controller with 64MB of DDR RAM Do I have this right: ATI sounds the way to go for linux support even though the driver is not quite there yet? While the choice is not offered in NZ I should push for it? Walter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
Sat Dec 15 2001, Mark Vojkovich wrote: > >So, it's going to change at sometime when there's an official > API. XFree86 will be backwards compatible with the old > protocol but the sample implementation and all the commercial > vendors won't acknowledge the current protocol. You just have > to keep that in mind, and you'll be expected to rewrite all > your Xinerama awareness code at some point if you want it to > work with anything other than XFree86. The current solution > was a hack to keep the Enlightenment guys happy. I understand that things will have to be rewritten when there is an official standard. But since many progams/people uses Xinerama as it is now, would it be possible to add this feature (physical size) to the existing non official API or do you expect an official API soon? Or should I just use an external config file where the user can specifiy the sizes of the screens for the time until the official API ? I understand if you don't have the time to do this, but do you think it would be a good idea? At least this possibility should be in the official version. I have another question about Xinerama too. Is it possible to have several resolutions configured and switch with <+/-> on individual screens or all together or not at all when Xinerama is enabled? This is nothing I _want_, just curious if it is a case one should handle. /Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Font + antialiasing fsckes up certain characters
Around 20 o'clock on Dec 15, Peter Surda wrote: > I have a question about fonts. When using antialiased fonts, the character > c+caret (that's what I think it's called, it's used in several Slavic Central > European languages and is of course in iso-8859-2) doesn't get displayed, Anti-aliased fonts are always in Unicode; your application may not be correct translating from the Latin-2 encoding to Unicode. You might give this a try with a Qt application and see if it works right. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
Sat Dec 15 2001, Mark Vojkovich wrote: > On Sat, 15 Dec 2001, Bj|rn Englund wrote: > > > First of all, is there any documentation for Xinerama except > > the Xinerama.h file? > >Pretty much. That is pretty much it? So there are no plans to write up a man page or so? I didn't see any man page. I can write one if it's ok? > > > > > From what I've seen there is no way to get the > > physical size of the monitors that are used for the different > > screens in Xinerama. Is this true? If so, will it > > be fixed/added? > >I thought it was pretty obvious how to do that from the > description in Xinerama.h. Ok could you please tell me then, I don't find it obvious. I understand how to get the screen resolution, but what I want is the _physical_ size (in mm) of the display, like what you get from DisplayWidthMM. I need it to calculate the aspect of the screen. /Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SiS630 - the neverending story
Is everybody on vacation? :) I wrote: > Addendum: > > Egbert seems to be right with his assumption that X is spinning in a > waiting loop within the 2D engine when switching back to X from another > VT. > > How do I know this? Simply set the option "NoAccel" in XF86Config-4 - > and it will work! Even better and easier: Set Option "TurboQueue" to "false" (and leave "NoAccel" out) - this gives you acceleration and does not freeze X on switching VTs. In case the driver does not work, try removing all ModeLine statements from your XF86Config-4 file. I have been running the driver the entire day, with a lot of switching VTs and APM events, it never crashed or distorted the display. Thomas PS: I am currently debugging the sisfb driver - this piece of sh*t is pure chaos. In init.c are three (!) different (!) procedures to detect the video bridge - two of which work, one is completely out of date. The driver oopses and "melts the screen" on my machine because it detects a SiS302B video bridge (which is obviously wrong, since my machine has a LVDS bridge, which is correctly detected by the X driver) and tries to initialize the CRT1 (!) group - which I believe is meant for 310 and 315 chipsets only. Because of this, the driver (correctly) skips initializing the pointers to its 310-refreshtables - but later (because of his erratious assumption of a SiS302B bridge) tries to access them anyway. On the other hand, there are lots of wonderful LVDS tables in the files, but the driver simply ignores them after all - there is not a single reference to these tables! I can't imagine a single machine with a SiS630 (and possibly a LCD panel) where this driver does not crash! (Rene?) I believe, sisfb is the result of a lot of people "fixing" it for their very own machines only, breaking stuff for others. Who am I talking to by the way? I think I need some sleep. -- Thomas Winischhofer Vienna/Austria mailto:[EMAIL PROTECTED] *** http://www.webit.com/tw ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama api
On Sun, 16 Dec 2001, Bj|rn Englund wrote: > Sat Dec 15 2001, Mark Vojkovich wrote: > > On Sat, 15 Dec 2001, Bj|rn Englund wrote: > > > > > First of all, is there any documentation for Xinerama except > > > the Xinerama.h file? > > > >Pretty much. > That is pretty much it? > So there are no plans to write up a man page or so? Not with this API. > I didn't see any man page. I can write one if it's ok? This API isn't official. It's something I hacked up. The original protocol was in the "PanoramiX" namespace (the original name for Xinerama) and wouldn't even tell you where the screens were at on the physical desktop - useless. I've gotten some flak already for making my own protocol without consulting X.org first. But then of course, if I waited for X.org to approve it you wouldn't have any protocol today because the official API still isn't finalized. So, it's going to change at sometime when there's an official API. XFree86 will be backwards compatible with the old protocol but the sample implementation and all the commercial vendors won't acknowledge the current protocol. You just have to keep that in mind, and you'll be expected to rewrite all your Xinerama awareness code at some point if you want it to work with anything other than XFree86. The current solution was a hack to keep the Enlightenment guys happy. > > > > > > > > From what I've seen there is no way to get the > > > physical size of the monitors that are used for the different > > > screens in Xinerama. Is this true? If so, will it > > > be fixed/added? > > > >I thought it was pretty obvious how to do that from the > > description in Xinerama.h. > > Ok could you please tell me then, I don't find it obvious. > I understand how to get the screen resolution, but what I want is > the _physical_ size (in mm) of the display, like what you get from > DisplayWidthMM. I need it to calculate the aspect of the screen. > I misunderstood you. No there isn't anyway to do that. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fourcc Codes
Vladimir Dergachev ([EMAIL PROTECTED]): > > > I don't think any drivers are using RGB formats. Also, there > > > aren't unambiguous fourcc codes for RGB as far as I can tell. > > > > Need to start somewhere to encourage driver writers to support RGB > > overlay surfaces. Why don't we start by standardizing what X uses > > for RGB fourccs. > > Are there any open source applications that use these ? I don't know any. If linux Xv drivers supported RGB surfaces with hardware scaling, I'd port every emulator and 2d game to it right away. Does nobody else find it really annoying that you can't play snes9x in fullscreen with nice hardware scaling? As an application developer I know I've been waiting for hardware scaling for quite some time. Xv is a convenient API to provide it. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fourcc Codes
On Sat, 15 Dec 2001, Billy Biggs wrote: > Mark Vojkovich ([EMAIL PROTECTED]): > > > > The "fourcc.h" file does not contain any RGB formats. Is there any > > > particular reason for this??http://www.webartz.com/fourcc has > > > standard RGB formats defined as well. Why not include them for the > > > next release. > > > > I don't think any drivers are using RGB formats. Also, there aren't > > unambiguous fourcc codes for RGB as far as I can tell. > > Need to start somewhere to encourage driver writers to support RGB > overlay surfaces. Why don't we start by standardizing what X uses for > RGB fourccs. Are there any open source applications that use these ? I don't know any. Vladimir Dergachev > > Unfortunately in the Windows world, you construct a 565 overlay by > using the RGB bitfield fourcc and setting some other parameter to ask > for 565, from what I remember. > > -- > Billy Biggs > [EMAIL PROTECTED] > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nobody in the Newbie list can answer this question. (tried for2-3weeks) Would someone please take a look?
Michael Krzenski wrote: > > > The following is a complete description of my system and the problem I'm > having with XFree86 CVS (Latest release as of 12/7/2001). Thanks for > taking the time to help me out. > > SYSTEM INFO: > *HP Pavilion N5495 Laptop > *i830M chipset > *RedHat Linux 7.2 > > PREVIOUS VERSION OF XFREE86 AND WHERE IT WAS INSTALLED: > *XFree86 4.1.0 > *Was installed in /usr/X11R6 and /etc/X11 > *Has since been mv'd out of the way > > CVS VERSION I'M INSTALLING AND WHERE I'M INSTALLING IT TO: > *Latest CVS as of 12/7/2001 > *Installing in /usr/X11R6 and /etc/X11 > > THE EXACT STEPS I TAKE TO INSTALL THE CVS: > *I make a directory and lndir the xc directory into it > *I edit the the site.def and uncomment the HasGcc2 > *I then runmake World >& world.log and tail -f the world.log > *I finnallymake install >& install.log and tail -f the install.log > > PROBLEM INCLUDING PARTIAL LOG: > *Fails with a list of unresolved symbols and then "Fatal server error: > Caught signal 11. Server aborting" everytime I run xf86cfg or XFree86 > -configure. > > (Unresolved symbols shown in the paritial log below) > > EVERYTHINGS FINE ABOVE THIS POINT > (II) Loading /usr/X11R6/lib/modules/linux/libint10.a > (II) Module int10: vendor="The XFree86 Project" > compiled for 4.1.99.1, module version = 1.0.0 > ABI class: XFree86 Video Driver, version 0.5 > > AND THEN ALL HELL BREAKS LOOSE > Symbol fbdevHWGetLineLength from module > /usr/X11R6/lib/modules/drivers/fbdev_drv.o is unresolved! > Symbol fbdevHWGetLineLength from module > /usr/X11R6/lib/modules/drivers/fbdev_drv.o is unresolved! > Symbol fbdevHWSaveScreen from module > /usr/X11R6/lib/modules/drivers/fbdev_drv.o is unresolved! > Symbol fbdevHWDPMSSet from module > /usr/X11R6/lib/modules/drivers/fbdev_drv.o is unresolved! > Symbol fbdevHWGetType from module > /usr/X11R6/lib/modules/drivers/fbdev_drv.o is unresolved! > Symbol shadowAdd from module /usr/X11R6/lib/modules/drivers/fbdev_drv.o > is unresolved! (snipped...) This looks like the RH 7.2/gcc trouble with X CVS. I believe it's fixed in CVS, so an update should resolve it (it's related to the no-merge-constants flag needed with RH's gcc.) Also, Redhat (Mike Harris) has rpms available at ftp://people.redhat.com/mharris/testing. -- Kevin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Font + antialiasing fsckes up certain characters
Hi guys! I have a question about fonts. When using antialiased fonts, the character c+caret (that's what I think it's called, it's used in several Slavic Central European languages and is of course in iso-8859-2) doesn't get displayed, the place where it should be is empty. This isn't font-specific (happens with everything I tried including truetype fonts) or distribution-specific (both mandrake 8.0 and RH 7.2 "vulnerable" :-)) Turning off antialiasing fixes it. As far as I know, this one character, both in lowercase and uppercase, is the only one experiencing this. I made a 11kB big screenshot of the situation, you can see it at http://panorama.sth.ac.at/font.png There are 2 rows displaying all the characters you need for Slovak, Czech and German language if you use ISO-8859-2 (i.e. it is the same text file, once in konqueror and once in konsole+less). Upper row is with antialiasing, lower without. You can clearly see that in the places where c+caret and C+caret is in the bottom row, it is missing in the top row. Any hints on what is causing this and how to fix it? It's been like this at least for half a year. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Don't drink and su. msg02489/pgp0.pgp Description: PGP signature
Re: [Xpert]Tearing on overlay surfaces
Mark Vojkovich ([EMAIL PROTECTED]): > > Do other drivers spin on a call to XvPut if the refresh is occuring? > > No. If you send faster than the retrace on NVIDIA hardware I just let > it shear because I don't want the X-server eating CPU. Below the > refresh rate, it won't shear. After a discussion on IRC, I'm not sure if this is such a good idea. It was noted that we'll get shearing on fast-forward and also when I'm scanning through a video in my NLE. More reasons the X server should export more information about what's going on in the hardware... -- Billy Biggs [EMAIL PROTECTED] http://www.billybiggs.com/ [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Fourcc Codes
Mark Vojkovich ([EMAIL PROTECTED]): > > The "fourcc.h" file does not contain any RGB formats. Is there any > > particular reason for this??http://www.webartz.com/fourcc has > > standard RGB formats defined as well. Why not include them for the > > next release. > > I don't think any drivers are using RGB formats. Also, there aren't > unambiguous fourcc codes for RGB as far as I can tell. Need to start somewhere to encourage driver writers to support RGB overlay surfaces. Why don't we start by standardizing what X uses for RGB fourccs. Unfortunately in the Windows world, you construct a 565 overlay by using the RGB bitfield fourcc and setting some other parameter to ask for 565, from what I remember. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xinerama api
First of all, is there any documentation for Xinerama except the Xinerama.h file? >From what I've seen there is no way to get the physical size of the monitors that are used for the different screens in Xinerama. Is this true? If so, will it be fixed/added? The normal X call only report the size of the monitor that is used for the first Xinerama screen. /Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]X server problem that causes SSH X forwarding to fail
Hi all, At first I thought I had an SSH problem as normal text mode SSH works but X11 forwarding doesn't. I think something is borked in my X settings. All this happened after I had to switch to DHCP. Here is an abreviated log of an X session, showing just the start and stop errors: Script started on Fri Dec 14 18:28:12 2001 xauth: (argv):1: bad display name "c888746-a.attbi.com:0" in "list" command xauth: (argv):1: bad display name "c888746-a.attbi.com:0" in "add" command xauth: (argv):1: bad display name "c888746-a.attbi.com:0" in "remove" command Script done on Fri Dec 14 18:28:40 2001 And here is the output of "xauth list": c888746-a.attbi.com/unix:0 MIT-MAGIC-COOKIE-1 e0cae68d99242 Note that the "/unix" is not present in the session display name. I wonder that is going wrong? Thanks in advance for any help. Rob. -- The Numeric Python EM Project www.pythonemproject.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SiS630 - the neverending story
Addendum: Egbert seems to be right with his assumption that X is spinning in a waiting loop within the 2D engine when switching back to X from another VT. How do I know this? Simply set the option "NoAccel" in XF86Config-4 - and it will work! I think we will have to reset the accelleration engine either when switching away from the server or when switching back. I am currently trying to find a awy to do this (yet unsuccessfully...) Thomas -- Thomas Winischhofer Vienna/Austria Check it out: mailto:[EMAIL PROTECTED] *** http://www.webit.com/tw ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
