Re: [Xpert]HyperPen5000 U PC Tablet
Hi again, My my pctablet works now it was just a matter of my USB configuration. I installed the Preliminary USB device filesystem and loaded the HID module and set up XF86Config file again. Markus ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]outline patterns
Hi! First of all, I'm not on this list, so would you please reply to my own address :) My problem: I'm using Qt in an app and I fill for example a circle with a pattern i use the QBrush class to set a pixmap as fill pattern the same stuff isn't possibe for the QPen class, which handles the outline of a shape I wonder if this can be done using some X calls So my question is, how to set a stroke pattern on a shape? Thank you in advance Bye Bye Niko -- Nikolas Zimmermann [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re:
[Xpert]CVS from Dec. 2nd broken on Linux: errno problems
Hi, I'm running XFree86 from CVS 1-week old and decided to keep current with the DGA 2 ATI fix. But, trying to recompile XFree86 from CVS (Dec. 2nd) on Linux x86, egcs 2.91.66 with 'make World', Linux kernel 2.4.16 headers (also tried Linux 2.4.14 headers with smylink to /usr/src/linux), RedHat 6.2, I get this error: (I guess this is related to Matthieu Herrb's recent commits on errno code) I also tried as root, but there's no difference, it seems like the files are here but imake does not see them. pc1: ~/xc % make World 18:24 #18 Building Release 6.5 of the X Window System. I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Sun Dec 2 18:24:34 CET 2001 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/home/cahagn_o/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap make[1]: Leaving directory `/home/cahagn_o/xc/config/imake' make Makefile.boot make[1]: Entering directory `/home/cahagn_o/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/home/cahagn_o/xc/config/imake' making imake with BOOTSTRAPCFLAGS= in config/imake cc -o ccimake -O -I../../include -I../../imports/x11/include/X11 ccimake.c cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c In file included from /usr/include/signal.h:300, from imake.c:178: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from imake.c:230: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory make[2]: *** [imake.o] Error 1 make[2]: Leaving directory `/home/cahagn_o/xc/config/imake' make[1]: *** [imake.proto] Error 2 make[1]: Leaving directory `/home/cahagn_o/xc' make: *** [World] Error 2 -- [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CVS from Dec. 2nd broken on Linux: errno problems
the asm symlink is missing. - Erwin On Sun, 2001-12-02 at 18:43, Olivier Cahagne wrote: Hi, I'm running XFree86 from CVS 1-week old and decided to keep current with the DGA 2 ATI fix. But, trying to recompile XFree86 from CVS (Dec. 2nd) on Linux x86, egcs 2.91.66 with 'make World', Linux kernel 2.4.16 headers (also tried Linux 2.4.14 headers with smylink to /usr/src/linux), RedHat 6.2, I get this error: (I guess this is related to Matthieu Herrb's recent commits on errno code) I also tried as root, but there's no difference, it seems like the files are here but imake does not see them. pc1: ~/xc % make World 18:24 #18 Building Release 6.5 of the X Window System. I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Sun Dec 2 18:24:34 CET 2001 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/home/cahagn_o/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap make[1]: Leaving directory `/home/cahagn_o/xc/config/imake' make Makefile.boot make[1]: Entering directory `/home/cahagn_o/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/home/cahagn_o/xc/config/imake' making imake with BOOTSTRAPCFLAGS= in config/imake cc -o ccimake -O -I../../include -I../../imports/x11/include/X11 ccimake.c cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c In file included from /usr/include/signal.h:300, from imake.c:178: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from imake.c:230: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory make[2]: *** [imake.o] Error 1 make[2]: Leaving directory `/home/cahagn_o/xc/config/imake' make[1]: *** [imake.proto] Error 2 make[1]: Leaving directory `/home/cahagn_o/xc' make: *** [World] Error 2 -- [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert msg01951/pgp0.pgp Description: PGP signature
[Xpert]Re: CVS from Dec. 2nd broken on Linux: errno problems
Olivier Cahagne wrote (in a message from Sunday 2) (I guess this is related to Matthieu Herrb's recent commits on errno code) I also tried as root, but there's no difference, it seems like the files are here but imake does not see them. [...] cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c In file included from /usr/include/signal.h:300, from imake.c:178: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from imake.c:230: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory Hmm, I doubt it's my fixes that are causing this. I didn't touch imake for now. And it still builds on a RedHat 7.0/i386 system I use for testing. This looks to me more like the traditional breakage when installed kernel headers don't match the ones for glibc. Linux is not the system I have the more experience with, so I'm not able to suggest you a fix. Matthieu ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CVS from Dec. 2nd broken on Linux: errno problems
Erwin, the asm symlink is missing. That's also what I thought, but I succeeded compiling XFree from CVS 1 week ago with 2.4.15 so I didn't double-checked. However, you were right, /usr/src/linux/include does not have an 'asm/' dir anymore but arch-specific directories such as 'asm-i386/'. According to fhs, that's what I should have done long time ago anyway: http://www.pathname.com/fhs/2.0/fhs-6.1.5.html (But, then, this is incorrect and should be modified: http://www.linuxdoc.org/FAQ/Linux-FAQ/x1698.html#AEN1848 ) So I modified /usr/include/asm to smylink to ../src/linux/include/asm-i386 instead of ../src/linux/include/asm However, I don't understand why this error shows only now. Can it be that the recent commit trigger this error ? PS: Matthieu, sorry about that, I really thought your recent commit and my specific error were related. Perhaps it just enlightened a long-lasting error on my system. I believe your RH7.2 test system as a correct asm symlink. -- [EMAIL PROTECTED] On Sun, 2001-12-02 at 18:43, Olivier Cahagne wrote: Hi, I'm running XFree86 from CVS 1-week old and decided to keep current with the DGA 2 ATI fix. But, trying to recompile XFree86 from CVS (Dec. 2nd) on Linux x86, egcs 2.91.66 with 'make World', Linux kernel 2.4.16 headers (also tried Linux 2.4.14 headers with smylink to /usr/src/linux), RedHat 6.2, I get this error: (I guess this is related to Matthieu Herrb's recent commits on errno code) I also tried as root, but there's no difference, it seems like the files are here but imake does not see them. pc1: ~/xc % make World 18:24 #18 Building Release 6.5 of the X Window System. I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Sun Dec 2 18:24:34 CET 2001 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/home/cahagn_o/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap make[1]: Leaving directory `/home/cahagn_o/xc/config/imake' make Makefile.boot make[1]: Entering directory `/home/cahagn_o/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/home/cahagn_o/xc/config/imake' making imake with BOOTSTRAPCFLAGS= in config/imake cc -o ccimake -O -I../../include -I../../imports/x11/include/X11 ccimake.c cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c In file included from /usr/include/signal.h:300, from imake.c:178: /usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from imake.c:230: /usr/include/linux/errno.h:4: asm/errno.h: No such file or directory make[2]: *** [imake.o] Error 1 make[2]: Leaving directory `/home/cahagn_o/xc/config/imake' make[1]: *** [imake.proto] Error 2 make[1]: Leaving directory `/home/cahagn_o/xc' make: *** [World] Error 2 -- [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xserver not restoring text mode properly with Matrox G450?
I've noticed recently that the X server doesn't seem to restore text mode properly, if I boot using the vga=030a (132x43 text mode) Linux kernel option. This video card is a Matrox G450, with XFree86 4.1.0 on Debian unstable (i386). The symptom is that my monitor reports Invalid Scan Frequency when I exit X (or use Ctl-Alt-Fx to switch to a text console), and the display is of course unrecognizable. I've checked the monitor settings in XF86Config-4, and they're all correct according to the manual. If I swap the G450 with a G400 borrowed from another box, everything works correctly. Has anyone else run into this? I've browsed the list archives and run some Google searches, but didn't see anything which appears relevant. Thanx! ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xserver not restoring text mode properly with Matrox G450?
On Sun, Dec 02, 2001 at 01:31:46PM -0600, Greg Norris wrote: I've noticed recently that the X server doesn't seem to restore text mode properly, if I boot using the vga=030a (132x43 text mode) Linux kernel option. This video card is a Matrox G450, with XFree86 4.1.0 on Debian unstable (i386). The symptom is that my monitor reports Invalid Scan Frequency when I exit X (or use Ctl-Alt-Fx to switch to a text console), and the display is of course unrecognizable. I've checked the monitor settings in XF86Config-4, and they're all correct according to the manual. I've got a similar situation with an identical card and linux distro. I can repeatably freeze the console with the following procedure: startx from the console, with no window manager, only launching an xterm. log in to another virtual console as the same user you started X as, 'export DISPLAY=:0.0'; and start a window manager (actually, any X client, I think). switch back to the graphical console (should now be displaying a window manager), and kill the xterm (ctrl-d). switch to the virtual console where I started the window manager, and kill the window manager. at this point the console hangs; displaying a blank (tho not dark) screen. attempting to switch to any virtual console results in the rendering of a series of short, vertical (mostly red green) lines at the top of the screen. machine is still active, and I can SSH in Greg, can you try doing this, and see if it happens on your machine as well? It doesn't happen to me if I don't load the DRI stuff. I've tested this with kernel 2.4.9-ac3, 2.4.14, and 2.4.16. I don't have framebuffer support in my kernel; as someone on #dri suggested removing it to see if it fixes another DRI lockup problem (after playing Half-Life [under wine] or Rune [from loki] for some time, the screen will hang). I actually never got console framebuffer working with my G450... hung every time, with the early 2.4 kernels I tried. I submitted a lengthy and detailed bug report to [EMAIL PROTECTED]; is it appropriate to repost it here? (I'm new to this list). Care Soderstrom. -- Network Engineer Real-Time Enterprises (952) 943-8700 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xserver not restoring text mode properly with Matrox G450?
That doesn't seem to be a problem here... when I kill the xterm I just get dumped back to a (working) text console. I tried both with and without DRI enabled, after booting with the default (80x25) text mode. On Sun, Dec 02, 2001 at 01:55:47PM -0600, Carl Wilhelm Soderstrom wrote: I've got a similar situation with an identical card and linux distro. I can repeatably freeze the console with the following procedure: startx from the console, with no window manager, only launching an xterm. log in to another virtual console as the same user you started X as, 'export DISPLAY=:0.0'; and start a window manager (actually, any X client, I think). switch back to the graphical console (should now be displaying a window manager), and kill the xterm (ctrl-d). switch to the virtual console where I started the window manager, and kill the window manager. at this point the console hangs; displaying a blank (tho not dark) screen. attempting to switch to any virtual console results in the rendering of a series of short, vertical (mostly red green) lines at the top of the screen. machine is still active, and I can SSH in Greg, can you try doing this, and see if it happens on your machine as well? It doesn't happen to me if I don't load the DRI stuff. I've tested this with kernel 2.4.9-ac3, 2.4.14, and 2.4.16. I don't have framebuffer support in my kernel; as someone on #dri suggested removing it to see if it fixes another DRI lockup problem (after playing Half-Life [under wine] or Rune [from loki] for some time, the screen will hang). I actually never got console framebuffer working with my G450... hung every time, with the early 2.4 kernels I tried. I submitted a lengthy and detailed bug report to [EMAIL PROTECTED]; is it appropriate to repost it here? (I'm new to this list). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xserver not restoring text mode properly with Matrox G450?
On Sun, Dec 02, 2001 at 02:38:39PM -0600, Greg Norris wrote: That doesn't seem to be a problem here... when I kill the xterm I just get dumped back to a (working) text console. I tried both with and without DRI enabled, after booting with the default (80x25) text mode. hmmm... in your .xinitrc file, are you launching the xterm as a background process (with the at the end)? that way, when it dies, X won't follow it down. if you launch X with nothing in the .xinitrc file, does it start and then exit immediately? Mine doesn't; tho I used to be under the impression that this was the correct behavior; but for some reason it doesn't do that anymore. Carl Soderstrom -- Network Engineer Real-Time Enterprises (952) 943-8700 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Fw: [Xpert]Egbert Eich did you fix alle the LCD problems in the SIS-630?
Rune writes: (sorry about the first post René) in the commit: http://www.xfree86.org/pipermail/cvs-commit/2001-November/003475.html: 536. SiS driver: - Added fix to restore fbdev mode properly on VT switch/exit. - Improved LCD handling on SiS 630. - fixed screen blanking in SiS driver to properly blank LCDs (Egbert Eich). Improved, but by how much? Rune Petersen I don't know myself. It worked on the box I had for testing. It didn't work before. So give it a try. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CVS from Dec. 2nd broken on Linux: errno problems
On Sun, 2001-12-02 at 19:46, Carl Wilhelm Soderstrom wrote:
the kernel headers in /usr/src or /usr/include/linux, should be the ones
that *glibc* was built against; not the ones for your current kernel.
Absolutely. /usr/include/{linux,asm} shouldn't be symlinks but
directories shipped with glibc.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]hardware programming
Hi, does someone know any good book about hardware driver programming? Markus ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Default fonts for menus, dialogues, etc
Emacs lets the user customize the colors used by menus by customizing a special face. When the user sets the inverse video flag in that face, for Emacs to do the right thing it must be able to determine what colors would be used by default. It can check for resources to specify them, but what if there are no resources--what colors would be used then? One suggestion was that Emacs should define fallback resources to specify the foreground and background colors. That does enable Emacs to determine, always, what colors are to be used. But is this proper behavior for an application? It could mean an inconsistency between Emacs and other applications in regard to how they display menus. Is that a real issue? Is there some rule that says what the default menu colors should be when there are no resource to specify them? Or is each toolkit ideosyncratic in that regard? Currently Emacs supports the Athena widgets and LessTif/Motif. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Default fonts for menus, dialogues, etc
Cópia Richard Stallman [EMAIL PROTECTED]:
Hi,
Emacs lets the user customize the colors used by menus by customizing
a special face. When the user sets the inverse video flag in that
face, for Emacs to do the right thing it must be able to determine
what colors would be used by default. It can check for resources to
specify them, but what if there are no resources--what colors would be
used then?
Xaw uses the resources XtDefaultBackground and XtDefaultForeground, that
are actually the value of WhitePixelOfScreen and BlackPixelOfScreen, or the
inverse if the resource reverseVideo is set.
Unfortunately the values of {Black,White}Pixel of screen can only be set
when running at 1bpp, but not all XFree86 drivers support 1bpp, and not all
of them will use the XF86Config options to set these values.
One suggestion was that Emacs should define fallback resources to
specify the foreground and background colors. That does enable Emacs
to determine, always, what colors are to be used. But is this proper
behavior for an application? It could mean an inconsistency between
Emacs and other applications in regard to how they display menus. Is
that a real issue?
I believe shipping a /usr/X11R6/lib/X11/app-defaults/Emacs file for
specifying default resources would be a better idea, but fallback resources
aren't completely a bad solution, better yet if it's value is programable,
and the user knows it is a fallback resource. For example, in the xedit
lisp interpreter I am working on, one can say:
(require xt)
(setq main-shell
(xt-app-initialize 'app-context MyApp '((title . MyTitle))
'(*Background: some-color *Foreground: some-other-color)))
That will set main-shell to a handle for the shell widget and will at
the same step create a new global variable (or change the value of the
lexically binded variable) app-context to a handle for an XtAppContext
implicitly created by the function.
The prototype is:
xt-app-initialize app-context-return application-class optional options
fallback-resources
But it is still subject to changes (probably for handling command line
parameters), as there is not yet a formal release of the xedit lisp
interpreter. The adavantage of using the fallback-resources argument is that
the code becomes completely self-contained, no need for an external
configuration file.
Is there some rule that says what the default menu colors should be
when there are no resource to specify them? Or is each toolkit
ideosyncratic in that regard? Currently Emacs supports the Athena
widgets and LessTif/Motif.
I believe there is no rule for this, but every toolkit has some way to
determine how it will look if no configuration was made, in the case of
Athena, it will be a simple rectangular window with white-color background,
black-color foreground, and 1 pixel black-color border.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Tearing on overlay surfaces
I recently purchased a Matrox G400 (to play with TV-out).
I noticed nasty tearing when using my DVD player + XVideo. This is in
contrast to the i810 driver which will wait to blit if called during the
retrace. My code now spins on the VGA port, which fixed the tearing.
Since I really badly want to see a well-supported API to query the
vertical refresh, I'd hope that maybe this is a good chance to again
request help and support. (please!)
That said, since I'm sure most simple video apps don't care about
amortizing frame display time over refreshes and just want to avoid
tearing, maybe doing the i810 trick in the mga driver would be useful.
Do other drivers spin on a call to XvPut if the refresh is occuring?
Also, I wait for the refresh using something like this code:
void spin_until_refresh_complete( void ) {
for(;;) if( inb( 0x3da ) 8 ) break;
}
Does anyone know what VGA cards this could fail on? So far it's
worked great for my i815, G400, and TNT2.
--
Billy Biggs [EMAIL PROTECTED]
http://www.billybiggs.com/ [EMAIL PROTECTED]
msg01966/pgp0.pgp
Description: PGP signature
Re: [Xpert]Tearing on overlay surfaces
On Sun, 2 Dec 2001, Billy Biggs wrote:
I recently purchased a Matrox G400 (to play with TV-out).
I noticed nasty tearing when using my DVD player + XVideo. This is in
contrast to the i810 driver which will wait to blit if called during the
retrace. My code now spins on the VGA port, which fixed the tearing.
No, that's not what happens. The MGA driver doesn't double
buffer video so you get tearing. The i810 driver does so you
don't. I doubt spinning on the client side can do anything to
prevent tearing.
Since I really badly want to see a well-supported API to query the
vertical refresh, I'd hope that maybe this is a good chance to again
request help and support. (please!)
That said, since I'm sure most simple video apps don't care about
amortizing frame display time over refreshes and just want to avoid
tearing, maybe doing the i810 trick in the mga driver would be useful.
I think you misunderstand what the i810 driver is doing. The
hardware automatically queues requests to display the next frame
and does so automatically at the next retrace. Nearly all, if not
all, hardware works that way. The i810 driver only has to spin to slow
you down if you are sending stuff faster than the retrace, because
it can only queue one frame ahead.
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.
Also, I wait for the refresh using something like this code:
void spin_until_refresh_complete( void ) {
for(;;) if( inb( 0x3da ) 8 ) break;
}
Does anyone know what VGA cards this could fail on? So far it's
worked great for my i815, G400, and TNT2.
It won't necessarily work on those. It depends whether or
not I/O access is enabled. In the case of secondary cards, port
access to legacy VGA registers is typically disabled.
Mark.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
Mark Vojkovich ([EMAIL PROTECTED]):
I noticed nasty tearing when using my DVD player + XVideo. This is
in contrast to the i810 driver which will wait to blit if called
during the retrace. My code now spins on the VGA port, which fixed
the tearing.
No, that's not what happens. The MGA driver doesn't double buffer
video so you get tearing. The i810 driver does so you don't. I doubt
spinning on the client side can do anything to prevent tearing.
But if it double buffered it would still need to flip-on-retrace.
So you're saying that my spinning on the client is just making the
video not suck by coincidence?
I think you misunderstand what the i810 driver is doing. [...]
Thanks for the clarification.
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.
So, if I'm running my display at 59.94hz and sending it NTSC video,
there's no way for me to get in sync without having some way of querying
the refresh, yeah?
Also, I wait for the refresh using something like this code:
void spin_until_refresh_complete( void ) {
for(;;) if( inb( 0x3da ) 8 ) break;
}
Does anyone know what VGA cards this could fail on? So far it's
worked great for my i815, G400, and TNT2.
It won't necessarily work on those. It depends whether or not I/O
access is enabled. In the case of secondary cards, port access to
legacy VGA registers is typically disabled.
Ok, what do you mean by this? Is this a software or hardware setting
or what?
On startup I run: ioperm( 0x3da, 1, 1 ), and I also require root
access.
--
Billy Biggs
[EMAIL PROTECTED]
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
On Sun, 2 Dec 2001, Billy Biggs wrote:
Mark Vojkovich ([EMAIL PROTECTED]):
I noticed nasty tearing when using my DVD player + XVideo. This is
in contrast to the i810 driver which will wait to blit if called
during the retrace. My code now spins on the VGA port, which fixed
the tearing.
No, that's not what happens. The MGA driver doesn't double buffer
video so you get tearing. The i810 driver does so you don't. I doubt
spinning on the client side can do anything to prevent tearing.
But if it double buffered it would still need to flip-on-retrace.
Most hardware can't not flip on retrace. I believe the MGA
is one of the exceptions where you can program it to flip on a
particular line number, the special case of, which is flipping at
the retrace.
So you're saying that my spinning on the client is just making the
video not suck by coincidence?
You're still getting a tear, it's just always happenning at
the same place so it's not so noticeable. You've essentially
synced your software to the retrace, but there's no way the
X-server can copy the data to the overlay entirely within
the retrace. There's not enough time. The tear is just happening
a fixed time after the retrace.
I think you misunderstand what the i810 driver is doing. [...]
Thanks for the clarification.
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.
So, if I'm running my display at 59.94hz and sending it NTSC video,
there's no way for me to get in sync without having some way of querying
the refresh, yeah?
The i810 would stall you if it were displaying a frame and already
had another queued when you sent the next frame. I could do that, but
I chose not to. You can see the place in the nv driver where I had
code to do that and commented it out.
Also, I wait for the refresh using something like this code:
void spin_until_refresh_complete( void ) {
for(;;) if( inb( 0x3da ) 8 ) break;
}
Does anyone know what VGA cards this could fail on? So far it's
worked great for my i815, G400, and TNT2.
It won't necessarily work on those. It depends whether or not I/O
access is enabled. In the case of secondary cards, port access to
legacy VGA registers is typically disabled.
Ok, what do you mean by this? Is this a software or hardware setting
or what?
What if you have two VGA cards in the machine? Who gets 0x3da?
Not both obviously. The bios will disable access to one of them
and the card can't be accessed in that fashion. Drivers like
the nv and mga drivers don't program the card with port I/O.
They do memory mapped I/O for everything so it's really not even
necessary for proper server operation that the vga registers are
even operational. The XFree86 RAC code may very well disable
access to them. Actually, I thought it did, but I guess since
you are finding something there, it must not have.
Mark.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xserver not restoring text mode properly with Matrox G450?
If I swap the G450 with a G400 borrowed from another box, everything works correctly. Are you using the HAL module from Matrox? I have had the same problem with my G400 and the solution was to stop using HAL - it does sloppy textmode restoration. I have no idea why it would break with one and not the other though. Perhaps they fixed it in the Matrox driver for G400 but not G450? At any rate use the XFree drivers if at all possible. Ross Vandegrift [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xdm respawning too fast with chooser
I haven't run a chooser in a long time, but I never had problems with them under X11R5. Using RedHat Linux 6.2 or 7.1, trying to run xdm from inittab, the chooser will not work correctly if xdm (prefdem forced to use xdm) is statred with -nodaemon. Yet without -nodaemon, I get those stupid respawning too fast messages. Any idea where to look? Thanks, Miles ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
Also, I wait for the refresh using something like this code:
void spin_until_refresh_complete( void ) {
for(;;) if( inb( 0x3da ) 8 ) break;
}
Yeah, this loop was wrong. Sorry.
for(;i;--i) {
/* wait for the refresh to occur. */
if( (inb( BASEPORT ) 8) ) break;
}
/* now we're inside the refresh */
for(;i;--i) {
/* wait for the refresh to stop. */
if( !(inb( BASEPORT ) 8) ) break;
}
That's the actual cut-and-paste from my crap first-attempt code.
--
Billy Biggs
[EMAIL PROTECTED]
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
On Sun, 2 Dec 2001, Billy Biggs wrote: Mark Vojkovich ([EMAIL PROTECTED]): But if it double buffered it would still need to flip-on-retrace. Most hardware can't not flip on retrace. I believe the MGA is one of the exceptions where you can program it to flip on a particular line number, the special case of, which is flipping at the retrace. Should that first sentence be 'most hardware can flip on retrace' or 'can't flip on retrace' ? :) No. Most hardware cannot flip on anything but the retrace. Not flipping on the retrace usually isn't a possibility. If the mga is so smart, I'm surprised that the XVideo driver buggers it up. :(Is this a bug do you think? It's a feature. Double buffering takes twice as much video memory and there's not much of it due to the DRI stealing it all for 3D. So you're saying that my spinning on the client is just making the video not suck by coincidence? You're still getting a tear, it's just always happenning at the same place so it's not so noticeable. You've essentially synced your software to the retrace, but there's no way the X-server can copy the data to the overlay entirely within the retrace. There's not enough time. The tear is just happening a fixed time after the retrace. Um... According to my tests, the screen redraw only takes 0.064ms. What is a screen redraw? I thought you were using XvShmPutImage? That takes probably 4 or 5 ms to copy the data to framebuffer with that driver. Since I'm at 85hz, that leaves pretty much the whole 11ms to copy a single frame to the screen. That should be plenty of time. :) It's not doublebuffering. It is reading out the buffer while the data is being written into it. If you don't want to shear it has to happen during the vertical blanking. With XvShmPutImage, that's not possible and you have to be double buffering. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
Ah Mark Mark Mark Mark, I just got school'ed bigtime. I totally understand what you're saying now, and what's going on. Thanks for bringing me back to reality, and sorry it took so long. If the mga is so smart, I'm surprised that the XVideo driver buggers it up. :(Is this a bug do you think? It's a feature. Double buffering takes twice as much video memory and there's not much of it due to the DRI stealing it all for 3D. But if we can't double-buffer in the hardware then I get tearing, and this makes it useless to a DVD player. And you're right, my little retrace hack doesn't help much. What do you recommend? Um... According to my tests, the screen redraw only takes 0.064ms. What is a screen redraw? I thought you were using XvShmPutImage? That takes probably 4 or 5 ms to copy the data to framebuffer with that driver. Sorry, I needed schooling. I understand the problem now. Why does it take so long to copy the data to the framebuffer? Can't we use DMA here? Does it really take that long to just copy 512k? -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
Mark Vojkovich ([EMAIL PROTECTED]): But if we can't double-buffer in the hardware then I get tearing, and this makes it useless to a DVD player. And you're right, my little retrace hack doesn't help much. What do you recommend? You should use different hardware or rewrite the mga code to doublebuffer. Ok, I'll take a look at the code tomorrow. Why does it take so long to copy the data to the framebuffer? Can't we use DMA here? Does it really take that long to just copy 512k? It's a little more than that because the driver is using 4:2:2 internally. Copying the way it is doing you can't get much more than 160 MB/sec and uses the CPU the whole time. Hrm, I hope it doesn't just double each chroma scanline. I'm in fear now. Wish that was documented somewhere, I would have written a better chroma upsampler sooner. DMA won't make the transfer go any faster (it will probably be slower unless you're using 2x+ AGP), but it won't eat the CPU. The only drivers that do this are NVIDIA's binary drivers and supposedly some experimental ATI drivers that some people are working on. Maybe the i810 drivers do too, not that it would help, since the bandwidth is probably the same writing to video ram or the framebuffer. I still think that using DMA is essential for all drivers if the images doesn't require some conversion. I guess I'd be worried about drivers which require scanlines to be 32bit aligned. Too bad the Xv API doesn't allow for that. (or am I on crack again) -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]xserver not restoring text mode properly with Matrox G450?
:) I get a similar problem with : nvidia tnt2 64 mandrake 8.1 or 8.0 not always but occasionaly (with or without FB) no DRI (not for nvidia) X server crashes when i flip from X - text tty - X again then text mode consoles are displayed in the vidmode i was in in X sometimes causing garbage on the screen (green/red characters) I have no idea what could cause this ... Clive -Original Message- From: Carl Wilhelm Soderstrom [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 02, 2001 9:56 PM To: [EMAIL PROTECTED] Subject: Re: [Xpert]xserver not restoring text mode properly with Matrox G450? On Sun, Dec 02, 2001 at 01:31:46PM -0600, Greg Norris wrote: I've noticed recently that the X server doesn't seem to restore text mode properly, if I boot using the vga=030a (132x43 text mode) Linux kernel option. This video card is a Matrox G450, with XFree86 4.1.0 on Debian unstable (i386). The symptom is that my monitor reports Invalid Scan Frequency when I exit X (or use Ctl-Alt-Fx to switch to a text console), and the display is of course unrecognizable. I've checked the monitor settings in XF86Config-4, and they're all correct according to the manual. I've got a similar situation with an identical card and linux distro. I can repeatably freeze the console with the following procedure: startx from the console, with no window manager, only launching an xterm. log in to another virtual console as the same user you started X as, 'export DISPLAY=:0.0'; and start a window manager (actually, any X client, I think). switch back to the graphical console (should now be displaying a window manager), and kill the xterm (ctrl-d). switch to the virtual console where I started the window manager, and kill the window manager. at this point the console hangs; displaying a blank (tho not dark) screen. attempting to switch to any virtual console results in the rendering of a series of short, vertical (mostly red green) lines at the top of the screen. machine is still active, and I can SSH in Greg, can you try doing this, and see if it happens on your machine as well? It doesn't happen to me if I don't load the DRI stuff. I've tested this with kernel 2.4.9-ac3, 2.4.14, and 2.4.16. I don't have framebuffer support in my kernel; as someone on #dri suggested removing it to see if it fixes another DRI lockup problem (after playing Half-Life [under wine] or Rune [from loki] for some time, the screen will hang). I actually never got console framebuffer working with my G450... hung every time, with the early 2.4 kernels I tried. I submitted a lengthy and detailed bug report to [EMAIL PROTECTED]; is it appropriate to repost it here? (I'm new to this list). Care Soderstrom. -- Network Engineer Real-Time Enterprises (952) 943-8700 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert WARNING: This e-mail contains confidential information and any unauthorised use or interception is illegal. If this e-mail is not intended for you, you may not copy, distribute or disclose the contents to anyone nor take any action in reliance on the content. If you receive this in error, please contact the sender and delete the material from any computer.
[Xpert]About RECORD extension
hi,I everyone! I am new here! And I got a problem in using RECORD extension. I hope the extension can record the changed area of screen when I do screen sampling. And I found the recorded data is sended throught the callback function. But what puzzleed me is that I can't find the coordinates and width and height in the recorded data. So, could you tell me how can I get the coordinates and width and height of changed area from the data recorded by RECORD extension. Please do me a favor! __ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]I'm leaving, permanently. (fwd)
Sprague, IT3 said... From [EMAIL PROTECTED] Mon Dec 3 00:34:21 2001 Return-Path: [EMAIL PROTECTED] Received: from dnsmail1.naples.navy.mil ([EMAIL PROTECTED] [138.180.190.68]) by rru.com (8.9.3/8.9.3) with ESMTP id AAA20726 for [EMAIL PROTECTED]; Mon, 3 Dec 2001 00:34:15 -0600 Received: from msceur-exch3.naples.navy.mil ([138.180.111.14]) by dnsmail1.naples.navy.mil (8.11.6/8.11.6) with ESMTP id fB36eGi13722 for [EMAIL PROTECTED]; Mon, 3 Dec 2001 07:40:19 +0100 Received: by MSCEUR-EXCH3 with Internet Mail Service (5.5.2650.21) id YD2Z7FR0; Mon, 3 Dec 2001 06:34:18 - Message-ID: E152F2FB0B24D511B60A000347228C7048394F@MSCEUR-EXCH3 From: Sprague, IT3 [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RE: [Xpert]I'm leaving, permanently. Date: Mon, 3 Dec 2001 06:34:17 - MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain This is real. The spam was from my boss (division officer), attempting to discern the source of the worm sent to this list a few days ago. This worm caused this list to be categorized as a security problem, and so I was ordered to leave. I believe the domain has been blackholed, also. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 5:28 PM To: Sprague, IT3 Subject: Re: [Xpert]I'm leaving, permanently. Eric, | |I've been ordered to unsubscribe from these lists and never return. I may |still be able to send personal mail to list members, but this is unlikely. | |Thanks for all the assistance, | |Eric W. Sprague, IT3, USN Is this real? (We had a spam from a .mil address this morning, so I wonder...) If so, may I ask why? -Miles ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
On Sun, 2 Dec 2001, Billy Biggs wrote: Why does it take so long to copy the data to the framebuffer? Can't we use DMA here? Does it really take that long to just copy 512k? It's a little more than that because the driver is using 4:2:2 internally. Copying the way it is doing you can't get much more than 160 MB/sec and uses the CPU the whole time. Hrm, I hope it doesn't just double each chroma scanline. I'm in fear now. Wish that was documented somewhere, I would have written a better chroma upsampler sooner. It just doubles each chroma line. That's all the nv driver does. I'm not sure there's any preprocessing that would make the result more accurate. Fact of the matter is most hardware can't do planar YCbCr formats due to the high bandwidth requirements. I don't know of anybody doing packed 4:2:0. Oh, I guess 3dfx does, but it still takes up 2 bytes per pixel and their conversion looks really bad. They don't seem to being doing CCIR 601 so it looks all washed out. DMA won't make the transfer go any faster (it will probably be slower unless you're using 2x+ AGP), but it won't eat the CPU. The only drivers that do this are NVIDIA's binary drivers and supposedly some experimental ATI drivers that some people are working on. Maybe the i810 drivers do too, not that it would help, since the bandwidth is probably the same writing to video ram or the framebuffer. I still think that using DMA is essential for all drivers if the images doesn't require some conversion. I guess I'd be worried about drivers which require scanlines to be 32bit aligned. Too bad the Xv API doesn't allow for that. (or am I on crack again) I'm not sure what you mean. Pretty much everything always needs to be 32 bit aligned. mpeg scanlines are always multiples of 16 pixels anyhow. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XtOpenDisplay() fails for :0.1 as a display string
Hi All,
XtOpenDisplay is getting thru for NULL as a
display string but I want to open with my own display
string like :0.0 and :0.1, but for this :0.0 is
working but :0.1 is getting fails what may be the
reason.
display1 = XtOpenDisplay(appcon, NULL, test1,
Test, NULL, 0, argc,
argv);
(I want to use like bellow one)
display1 = XtOpenDisplay(appcon, :0.1, test1,
Test, NULL, 0, argc,
argv);
in this I want instead of NULL = :0.0 and another as
:0.1 is it possible in Linux, if it is not then what
is the alternative for this type of opening displays.
Thanks in advance,
Bala.
--- [EMAIL PROTECTED] wrote:
Quoting Ba la [EMAIL PROTECTED]:
Hi Mark,
I am opening two displays using
XtOpenDisplay()
function call after that I am creating two shells
using XtAppCreateShell(), in that my first
function
XtAppCreateShell() succeeds, but the second
function
call to create shell using XtAppCreateShell fails
and
dumps the core, the parameters diff is the 1st
parameter app_name and the 4th parameter
Display(what
I got from XtOpenDisplay) remaining all same, I
didn't
find any syntax error in that 2nd call, then how
come
it is getting fails ???, (I am working in 8bpp
mode)
I am in the process of finding out the error,
can
you give me some hints on this issue.
my questions are,
** out of two createshell functions one is
succeeds
other fails, is it really error with
XtAppCreateSheel() function call or some errors
with
XtOpenDisplay itself,
** is ther anyway to check whether the
XtOpenDisplay
function executed properly and the display is
opened
for funther operation like that.
Hi,
I just wrote this small test program, and it seens
to work:
--
#include X11/Intrinsic.h
#include X11/StringDefs.h
#include X11/Shell.h
XtAppContext appcon;
Widget shell1, shell2;
Display *display1, *display2;
int
main(int argc, char *argv[])
{
Arg args[2];
Cardinal num_args;
XtToolkitInitialize();
num_args = 0;
XtSetArg(args[num_args], XtNwidth, 100);
++num_args;
XtSetArg(args[num_args], XtNheight, 100);
++num_args;
appcon = XtCreateApplicationContext();
display1 = XtOpenDisplay(appcon, NULL, test1,
Test, NULL, 0, argc,
argv);
display2 = XtOpenDisplay(appcon, NULL, test2,
Test, NULL, 0, argc,
argv);
shell1 = XtAppCreateShell(test1, Test,
applicationShellWidgetClass,
display1, args, num_args);
shell2 = XtAppCreateShell(test2, Test,
applicationShellWidgetClass,
display2, args, num_args);
XtRealizeWidget(shell1);
XtRealizeWidget(shell2);
XtAppMainLoop(appcon);
return (0);
}
--
I noticed that if you pass NULL as the argc
argument to XOpenDisplay, it
will try to deference it, so I believe the problem
you are seeing may be
passing NULL were a valid pointer is expected. I
didn't test connecting
to two different X servers, so there maybe some
problem in this case.
Thanks in advance.
Bala.
__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site
hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Paulo
__
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Tearing on overlay surfaces
Mark Vojkovich ([EMAIL PROTECTED]): Hrm, I hope it doesn't just double each chroma scanline. I'm in fear now. Wish that was documented somewhere, I would have written a better chroma upsampler sooner. It just doubles each chroma line. That's all the nv driver does. I'm not sure there's any preprocessing that would make the result more accurate. I was thinking you could interpolate the samples, but then I realized that you can't be gamma correct without doing an expensive conversion: Y'CbCr-R'G'B'-RGB-R'G'B'-Y'CbCr And then I realized the obvious, that MPEG's 4:2:0 sampling (in between on the left) makes doubling each chroma line the correct thing to do anyway. I still think that using DMA is essential for all drivers if the images doesn't require some conversion. I guess I'd be worried about drivers which require scanlines to be 32bit aligned. Too bad the Xv API doesn't allow for that. (or am I on crack again) I'm not sure what you mean. Pretty much everything always needs to be 32 bit aligned. mpeg scanlines are always multiples of 16 pixels anyhow. Well for planar formats, 720 luma samples is 720 bytes, and that just doens't align nicely. But yes, if you're using 4:2:2, 720*2 is nice and round. I find it interesting that all these overlays only use 4:2:2. Do you think I should move the conversion into my app and save them the trouble (and also improve my OSD compositing)? Sounds like a win to me. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: CVS from Dec. 2nd broken on Linux: errno problems
On 2 Dec 2001, Michel [ISO-8859-1] Dänzer wrote:
Absolutely. /usr/include/{linux,asm} shouldn't be symlinks but
directories shipped with glibc.
What? glibc doesn't have those directories, those should *indeed* be
symlinks to /usr/src/linux/include/linux and /usr/src/linux/include/asm
respectively. This is how most distro's do it (or at least used to do
it).
Since when did glibc have those directories?
ani
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Antigen found =*.vbs file
Antigen for Exchange found UUAICI.BMP.vbs matching =*.vbs file filter. The file is currently Removed. The message, Newbie digest, Vol 1 #744 - 15 msgs, was sent from [EMAIL PROTECTED] and was discovered in IMC Queues\Inbound located at Ensico/ENSICO/ENSICO01. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Antigen found =*.vbs file
Antigen for Exchange found UUAICI.BMP.vbs matching =*.vbs file filter. The file is currently Removed. The message, Newbie digest, Vol 1 #744 - 15 msgs, was sent from [EMAIL PROTECTED] and was discovered in IMC Queues\Inbound located at Ensico/ENSICO/ENSICO01. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]problem with XFree86, plz help
K, I got XFree86 working, I type 'startx' and it opens up twn, but when I tried to install kde which I installed from the port I replaced that line in the xinitrc file that says 'twn ' to 'startkde '. Well, after doing that I typed 'startx' and it started up but it looked like it loaded twn first and then loaded kde on top of that. After that when I log out of kde it goes to twn, so when I type 'exit' in the logon window my screen slowly fades to white and it doesn't respond to the ctrl+alt+backspace, I finally have to restart my system complety. I'm using this on FreeBSD 4.4 on a Dell Inspiron 8000 laptop with an ATI Mobility 4 card. Any suggestions or ideas on how I can resolve this problem would help. Thx, Dave ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
