Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
We already have a function call to disable VT switching. xf86EnableVTSwitch(Bool new) Call it with TRUE to enable VT Switching, and FALSE to disable. You should be able to do this in a driver. It was specifically added for DRI and fullscreen modes, although it should work for this case too. Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Radeon 7500 Dual Head Support
Does the current Xfree86 4.2.0 radeon driver support dual head operation? Are there any stipulations like same resolution on each head? If it is supported, can someone post an example XF86Config file. Thanks in advance. Shane __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: libxml needs iconv.h ?
Around 10 o'clock on Feb 17, Andrew C Aitchison wrote: moving a discussion from devel to xpert about XML configuration files Can I at least ask that changing to an XML format config file requires a major version increment, to version 5.0 if it happens now ? Sure, any change to the configuration file syntax will need to be well advertised and planned far in advance. A transition strategy will be needed. Having just experienced the real horror of a non-standard configuration file format, I will argue strongly that XML is a better solution than any custom configuration file format. Even for people editing the file with emacs. We are barraged weekly with questions about how to specify various configuration options in the config file. Yesterday, someone asked why the following failed: Option ZAxisMapping 4 5 I doubt fully half of this list's readership could solve this problem; it wasn't immediately obvious to me. It's not that the current syntax is bad, it's just different from everything else, as any custom configuration file sytax is. Moving to XML solves this problem -- the syntax is now regularized so questions about quoting and such won't occur. Automated tools are another problem; with the current syntax, comments inserted by the user will probably be lost when the file is read and rewritten by an external configuration tool. This means that you can either edit the file only by hand, or only with a GUI tool. Libxml preserves comments and formatting so that reading/writing the configuration file won't make it impossible to edit the file in the future with a text editor. Finally, using XML means that external tools needn't worry about additions to the configuration file syntax or contents -- the file is always parsable, and the configuration tool can simply ignore portions it doesn't understand without any question of whether the remaining portions of the file will be misunderstood. I had this particular problem with the Xft configuration file. Configuring fonts is of critical importance in a desktop environment. Xft provides a new level of customizability, and KDE wanted to expose that to the user. To get at the configuration file, they incorporated the Xft parser into their own code; they had little choice; there was no other way to extract the semantic meaning of even a portion of the file. This means that KDE can edit *one version* of the Xft configuration file, but any changes will break that support. I clearly needed to provide programmatic support for parsing the configuration file and regenerating it. I could have developed my own such mechanism, but I decided to try a different path -- using standard existing tools that already solved this problem. The results were very encouraging; I switched from a custom parser to XML in a day, developing a DTD and writing the tree-walking code was straightforward and also illuminated a few dark corners of the configuration file semantics. I also got to delete lots of code, which is always a good feeling. The resulting parser is more robust against failure and the file can be verified by external tools before attempting to install it in the system. This latter result would be very nice for XFree86 configuration files -- instead of starting the X server to discover a configuration file syntax problem, you'd run an external tool to verify the file, catching and fixing any errors found quickly. Sorry, are you suggesting that we include libxml2 code, or that we use the one in the system ? I'd certainly prefer that we use one installed by the system when available. For distributions with it, can we recommend that it the user install it rather than using a version we provide. Yes, the intent is to use the one provided by the system, but as libxml2 isn't widely available yet, XFree86 includes the source for systems that don't provide it, just as we provide source for things like the regex library and FreeType. Is it a new policy that XFree86 should only support reasonable systems ? It used to be a matter of pride that it ran on a wide range of platforms. No, the question is only how to support existing platforms while still providing new features. The case in question involves a system with optional support for a standard library function (iconv); we can easily support that system by requiring that the optional library be loaded for XFree86 to function. I'd include source for that library, but the license is incompatible with our source distribution, and it's not the only implementation. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Blanking and Unblanking screen
Hi, I have an app that displays images and videos in fullscreen. Often when killing the one program and starting the next there is a flicker and a glimpse of the desktop before the next image/video starts. I wonder if there is a way to blank the screen, for the period that I kill the one program and start the other, and then unblank the screen. Thanks Jonathan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Diabling Ctrl-Alt-F1 Keysequences Under X
On Sat, 16 Feb 2002, Christopher W. Allermann wrote: [...] I'm running Debian 2.2 Potato, Linux Kernel 2.2.17 and XFree86 3.3.6 (I know its not the latest, sorry about this. I'm in a rush to deploy, can always upgrade later.) Are you aware of the unofficial debs at http://people.debian.org/%7Ecpbotha/ ? Just adding these lines to /etc/apt/sources.list worked fine for me: deb http://people.debian.org/%7Ecpbotha/ xf403_potato/i386/ deb http://people.debian.org/%7Ecpbotha/ xf403_potato/all/ Unfortunately 4.2 hasn't appeared there yet (latest is 4.1; munge above lines to suit, obviously). HTH, Neale. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Blanking and Unblanking screen
On 17 Feb 2002, Jonathan Marks wrote: Hi, I have an app that displays images and videos in fullscreen. Often when killing the one program and starting the next there is a flicker and a glimpse of the desktop before the next image/video starts. I wonder if there is a way to blank the screen, for the period that I kill the one program and start the other, and then unblank the screen. See the man page on XSetScreenSaver and friends. One of those might do what you want. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
On Sun, 17 Feb 2002, Keith Packard wrote: Around 10 o'clock on Feb 17, Andrew C Aitchison wrote: moving a discussion from devel to xpert about XML configuration files Can I at least ask that changing to an XML format config file requires a major version increment, to version 5.0 if it happens now ? Sure, any change to the configuration file syntax will need to be well advertised and planned far in advance. A transition strategy will be needed. Having just experienced the real horror of a non-standard configuration file format, I will argue strongly that XML is a better solution than any custom configuration file format. Even for people editing the file with emacs. We are barraged weekly with questions about how to specify various configuration options in the config file. Yesterday, someone asked why the following failed: Option ZAxisMapping 4 5 I had the exact same questions and solved it with Option ZAxisMapping4 5 I am very strongly against XML configuration files.. XML is really rather poor for hand editing so it is best written by another program. If you are going to have another program write the file anyway you can just as well use the current syntax, it is no worse. I doubt fully half of this list's readership could solve this problem; it wasn't immediately obvious to me. It's not that the current syntax is bad, it's just different from everything else, as any custom configuration file sytax is. Moving to XML solves this problem -- the syntax is now regularized so questions about quoting and such won't occur. And plenty of other questions will occur. Automated tools are another problem; with the current syntax, comments inserted by the user will probably be lost when the file is read and rewritten by an external configuration tool. This means that you can I say that's a poorly written configuration program, I do not see it as too hard to retain the comments. either edit the file only by hand, or only with a GUI tool. Libxml preserves comments and formatting so that reading/writing the configuration file won't make it impossible to edit the file in the future with a text editor. Finally, using XML means that external tools needn't worry about additions to the configuration file syntax or contents -- the file is always parsable, and the configuration tool can simply ignore portions it doesn't understand without any question of whether the remaining portions of the file will be misunderstood. Do you really want a tool that does not understand complete syntax of the configuration file (let alone semantics) messing with Xserver configuration ? I had this particular problem with the Xft configuration file. Configuring fonts is of critical importance in a desktop environment. Xft provides a new level of customizability, and KDE wanted to expose that to the user. To get at the configuration file, they incorporated the Xft parser into their own code; they had little choice; there was no other way to extract the semantic meaning of even a portion of the file. This means that KDE can edit *one version* of the Xft configuration file, but any changes will break that support. I clearly needed to provide programmatic support for parsing the configuration file and regenerating it. I could have developed my own such mechanism, but I decided to try a different path -- using standard existing tools that already solved this problem. The results were very encouraging; I switched from a custom parser to XML in a day, developing a DTD and writing the tree-walking code was straightforward and also illuminated a few dark corners of the configuration file semantics. I also got to delete lots of code, which is always a good feeling. The resulting parser is more robust against failure and the file can be verified by external tools before attempting to install it in the system. This latter result would be very nice for XFree86 configuration files -- instead of starting the X server to discover a configuration file syntax problem, you'd run an external tool to verify the file, catching and fixing any errors found quickly. Not everything is a tree. Good that it works for you - it could also work in a number of other ways. If there _is_ a need for extending configuration file (despite the fact that the trend was to reduce its size and contents) may I humbly suggest something line based ? And if you really want to make a monster of it, why not tie XFree86 into Tcl and make XF86Config a Tcl script ? This would allow for a number of fancy things like, for example, autodetecting configuration at startup without mess of C code. Vladimir Dergachev ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Problems with xv and 4.2.0
Hi there, I am using the bttv driver from kernel 2.4.17, and XFree86 4.2.0 with a TVCapture 98 card from AverMedia and the v4l module for XFree86. The card works great, but if I increase the vertical geometry of xawtv to a number greater than 10, the image is compressed vertically to show only about half the real image. I guess that with this value, the resolution starts being greater than 480 and the driver, that should start showing both fields, get lost. This only happens if I set the TV norm to PAL-M, which we use here in Brazil. If I set it to NTSC, it works Ok, but then, of course, the colors are not correct (BW). I guess the v4l palm driver is the responsible. I can give more details if requested. Driver output: Linux video capture interface: v1.00 i2c-core.o: i2c core module i2c-algo-bit.o: i2c bit algorithm module bttv: driver version 0.7.83 loaded bttv: using 2 buffers with 2080k (4160k total) for capture bttv: Host bridge is VIA Technologies, Inc. VT8363/8365 [KT133/KM133] bttv: Bt8xx card found (0). PCI: Found IRQ 10 for device 00:0d.0 bttv0: Bt878 (rev 2) at 00:0d.0, irq: 10, latency: 32, memory: 0xe900 bttv0: detected: AVermedia TVCapture 98 [card=13], PCI subsystem ID is 1461:0002 bttv0: using: BT878(AVerMedia TVCapture 98) [card=13,autodetected] i2c-core.o: adapter bt848 #0 registered as adapter 0. bttv0: Avermedia eeprom[0x4002]: tuner=2 bttv0: i2c: checking for MSP34xx @ 0x80... not found bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874a,tda9850,tda9855,tea6300,tea6420, tda8425,pic16c54 (PV951) i2c-core.o: driver generic i2c audio driver registered. i2c-core.o: driver i2c TV tuner driver registered. tuner: chip found @ 0xc2 bttv0: i2c attach [client=Philips NTSC,ok] i2c-core.o: client [Philips NTSC] registered to adapter [bt848 #0](pos. 0). bttv0: PLL: 28636363 = 35468950 ... ok -- Roberto Jung Drebes [EMAIL PROTECTED] Porto Alegre, RS - Brasil http://www.inf.ufrgs.br/~drebes/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: libxml needs iconv.h ?
On 2002.02.18 01:06 Vladimir Dergachev wrote: On Sun, 17 Feb 2002, Keith Packard wrote: Around 10 o'clock on Feb 17, Andrew C Aitchison wrote: moving a discussion from devel to xpert about XML configuration files Can I at least ask that changing to an XML format config file requires a major version increment, to version 5.0 if it happens now ? Sure, any change to the configuration file syntax will need to be well advertised and planned far in advance. A transition strategy will be needed. Having just experienced the real horror of a non-standard configuration file format, I will argue strongly that XML is a better solution than any custom configuration file format. Even for people editing the file with emacs. ... I am very strongly against XML configuration files.. XML is really rather poor for hand editing so it is best written by another program. If you are going to have another program write the file anyway you can just as well use the current syntax, it is no worse. Most people write XHTML, DocBook XML and other XML DTDs by hand without any difficulties. XML can be a little too verbose, but in a configuration file, that's hardly noticed. ... It's not that the current syntax is bad, it's just different from everything else, as any custom configuration file sytax is. Moving to XML solves this problem -- the syntax is now regularized so questions about quoting and such won't occur. And plenty of other questions will occur. XML is a widely used standard. It's much more likely that one has seen an XML before on its life than an XF86Config file. This mean is easier to learn by repetition. Automated tools are another problem; with the current syntax, comments inserted by the user will probably be lost when the file is read and rewritten by an external configuration tool. This means that you can I say that's a poorly written configuration program, I do not see it as too hard to retain the comments. It's poorly written allright, but why spend time reinventing the weel, coding data structures for holding the comments, sections, options, unknown options, etc.? either edit the file only by hand, or only with a GUI tool. Libxml preserves comments and formatting so that reading/writing the configuration file won't make it impossible to edit the file in the future with a text editor. Finally, using XML means that external tools needn't worry about additions to the configuration file syntax or contents -- the file is always parsable, and the configuration tool can simply ignore portions it doesn't understand without any question of whether the remaining portions of the file will be misunderstood. Do you really want a tool that does not understand complete syntax of the configuration file (let alone semantics) messing with Xserver configuration ? The are lot of scenarios were one would want that. Why should a tool for configurating the desktop size and depth worry about the Z axis mapping of the mouse? ... If there _is_ a need for extending configuration file (despite the fact that the trend was to reduce its size and contents) may I humbly suggest something line based ? And if you really want to make a monster of it, why not tie XFree86 into Tcl and make XF86Config a Tcl script ? This would allow for a number of fancy things like, for example, autodetecting configuration at startup without mess of C code. Vladimir Dergachev Instead of making the XF86config a monster every configuration tool would had to be a even bigger monster.. Anyway, due to XML easy syntax there are very tiny XML parsers available, so this is not even an issue. For what is worth, I just want to say that IMHO the advantages of using XML heavily outweight its disadvantages. Regards, José Fonseca _ 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]Re: libxml needs iconv.h ?
On Mon, Feb 18, 2002 at 02:07:56AM +, José Fonseca wrote: Do you really want a tool that does not understand complete syntax of the configuration file (let alone semantics) messing with Xserver configuration ? The are lot of scenarios were one would want that. Why should a tool for configurating the desktop size and depth worry about the Z axis mapping of the mouse? It doesn't need to know about it, even now, because we have a library for reading/writing the config file. The tool just needs to deal with the data structures that it's interested in. There are legitimate arguments for using XML, but I'm not sure that all of the arguments put forward fall into that category. Instead of making the XF86config a monster every configuration tool would had to be a even bigger monster.. Anyway, due to XML easy syntax there are very tiny XML parsers available, so this is not even an issue. I know that libxml2 isn't the smallest one around, but the code size is about three times that of the parser in XFree86. The difference of course is that libxml2 isn't single-purpose. For what is worth, I just want to say that IMHO the advantages of using XML heavily outweight its disadvantages. The number one disadvantage I see is the change, and I know that nobody is advocating making the switch overnight. The basic XFree86 config file format has existed for a LONG time, and XML wasn't available as an option when it was first developed. I'd really like to see a proposed DTD for an XML-based XFree86 config file. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
