Re: [Xpert]error after server crash
On Thu, 2 Jan 2003 11:51:03 -0500 Jose Avalis [EMAIL PROTECTED] wrote: Hi there, I'm Jose from toronto After a power shutdown, I've restarted the server and I couldn't init the graphic interface. Logged in as root, when I try to start the graphic interface startx the screen turns black and I get the error logged in the attached file. The last part of the log file is the error you'd get if you forgot to start your font server. Is xfs running? Scott ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]error after server crash
On Thu, 2 Jan 2003 13:20:03 -0500 Jose Avalis [EMAIL PROTECTED] wrote: Sorry, I'm relatively new in Linux, I've tried to start fxs from command line, but nothing happened, should I specify any parameter?? thanks a lot. If you are using RedHat (other distros may be the same, I have no idea) the command: service xfs start should get XFS running. This is only a temporary solution, however. You really need to figure out WHY the font server isn't getting started automatically at boot. It could also be possible that XFS is unable to start for some reason (e.g., as someone else pointed out, there could be something like a stale lock file or other problem). Good luck, Scott Long ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM*****Extracting a KeySym from an action routine)
On Tue, 26 Nov 2002 21:30:51 +0100 Luca Olivetti [EMAIL PROTECTED] wrote: En/na David Dawes ha escrit: All I can really say so far without having analysed the data is that the number of false positives has been relatively small compared to Zero false positives is the only acceptable result, if you're using it to discard email. You won't get that with any of blacklists. As an author of one of the anti-spam abstracts Mr. Packard mentioned I can't help but comment here. IMHO blacklist systems are unethical because they work by holding ISP customers as hostages. The idea being, if you tick off enough people, they'll complain and get the ISP to fix their relays. The collateral damage due to this approach far outweighs any benefit gained by blocking spam. I'll pretend this list is a democracy, and cast my imaginary vote for deactivating the RBL checks in SpamAssassin. BTW, the archives of this list make up a sizeable portion of the email corpus we use to train and test our systems. Thanks, everybody ;-) Regards, Scott Long ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Antialias with video overlay ?
On Thu, 14 Nov 2002 15:02:49 +0100 David Balazic [EMAIL PROTECTED] wrote: David, More smooth is not necessarily less alias, as you put it. Smoothing filters work by spreading pixels values into surrounding pixels. The effect of this is to remove high frequencies from the image. But the goal of antialiasing is different. We don't want to make the resulting image smoother, per se, we want to make it more *accurate*. In other words, we want to consider pixel coverage on the sub-pixel level, and color pixels according to a more accurate scheme than If the center of the pixel is covered, then the pixel is on. There are two kinds of aliasing going on in your scheme. The first is the aliasing introduced by rendering: square pixel edges causing stairsteps. The second kind of aliasing is spatial aliasing, when you down-size the image to produce the final result (due to Nyquist's theorem). You can simultaneously remove both kinds of aliasing by coverage-averaging little chunks of the image into the final pixels. By this I mean that if a rectangle partially covers a source pixel by X amount, then that pixel will contribute X amount to the final color of the destination pixel. If we're scaling from a 4x4 group of pixels to a 1x1 group (down-size 4x), then each square of 16 pixels in the source will be averaged to produce the final destination pixel. You are suggesting using overlay with alpha to perform this task. Problem is, alpha works on a pixel-by-pixel basis. The color of the resulting pixel will only be affected by its color before. But to do filtering, you need to take into account the values of *other* pixels in the source. Alpha can't do that, you need a real filter. The other big disadvantage to this scheme is that you have to render the source image at double the size, which means you have to render four times as many pixels. This is in fact how programs like raytracers do antialiasing, but raytracers are extremely slow. Like I said, there are much better antialiasing methods for different situations, like drawing lines, polygons, glyphs, etc. Supersampled antialiasing on the scale of entire images is sort of a luxury of non-realtime rendering systems. Scott Long Your other options would make the image smoother, but only because they would blur the image. More smooth == less alias , or am I missing something ? You can't resize an image to a larger size and get more detail out of nothing. And we don't want more detail, just less alias. The only effect a filter would have would be to smear the image. Examples of use : - text anti-alias : render the text at lower resolution, then scale it up to some higher resolution, and get AA filtering for free - 3D FSAA : render at higher resolution, scale down to get FSAA ( using the same resolution ( 1:1 scaling ) might give something useful too ? ) Opinions ? Unfortunately, that won't work at all. What you want to do is render the text at a *higher* resolution and then scale the result *down* to the display resolution using coverage-weighted averaging. You can't get anything for free! If you tried what you suggest, what you'd end up with would be a blocky character that shows stairstepping, except the stairsteps would be blurry. Not only ugly, but a headache-inducer :-) I think proper filtering would remove the stairs ( the low res ones, the high res ones ( the final image ) depend on the way the RAM-DAC operates ) There are many (and *much* better) techniques for antialiasing fonts in particular that don't resort to this brute-force supersampling method. Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Antialias with video overlay ?
On Tue, 12 Nov 2002 15:09:37 +0100 David Balazic [EMAIL PROTECTED] wrote: I've been toying with this idea to use the video overlay feature as an efficient anti alias method. Is this doable ? Here is how it would work : set the display to some resolution ( higher is better ) render your picture ( at a lower , same or higher resolution than the display ) use the overlay to scale the picture to the physical screen cards with good scaling ( filtering etc. ) would make a nice smoothed picture , right ? The only option you mention that could possibly work would be to render the image at a *higher* resolution than the display resolution, then scale the image down using coverage-weighted averaging. This is known as supersampling and is how many AA algorithms work. Your other options would make the image smoother, but only because they would blur the image. You can't resize an image to a larger size and get more detail out of nothing. The only effect a filter would have would be to smear the image. Examples of use : - text anti-alias : render the text at lower resolution, then scale it up to some higher resolution, and get AA filtering for free - 3D FSAA : render at higher resolution, scale down to get FSAA ( using the same resolution ( 1:1 scaling ) might give something useful too ? ) Opinions ? Unfortunately, that won't work at all. What you want to do is render the text at a *higher* resolution and then scale the result *down* to the display resolution using coverage-weighted averaging. You can't get anything for free! If you tried what you suggest, what you'd end up with would be a blocky character that shows stairstepping, except the stairsteps would be blurry. Not only ugly, but a headache-inducer :-) There are many (and *much* better) techniques for antialiasing fonts in particular that don't resort to this brute-force supersampling method. Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]But *why* no vblank?
I must have seen about 10 requests/complaints on this list about no vblank sync support since I subscribed. The reply is always the same, that the vblank signal comes on an interrupt, and a usermode program such as X cannot get anywhere near it. I assume there are a number of issues surrounding vblank support. First, how does vblank fit into a network-transparent graphics protocol like X? How would the client request a particular operation to be sync'd to vblank? Obviously this syncing should occur on the server side, since a remote client can't receive the vblank signal for the local display. Also, how could the actual sync be performed? Could we have a device like /dev/vblank that blocks on read until the vblank interrupt is sent? Or some kind of ioctl? And what are the ramifications of having video code running in both the kernel and the X server? Will kernel-level video drivers interfere with X's drivers? How does X interact with the fbdev, currently? I realize that I've just asked a bunch of questions without really answering anything. But it's very frustrating to keep reading these requests for vertical sync support, and keep seeing answers that say That's just impossible, sorry. Oh, come on. We all know it isn't impossible; it's just a hairy problem that no one seems to want to deal with. It involves a bunch of compromises that people don't want to make. But this is an extremely *basic* feature that people are demanding and it doesn't seem right to just blow them off. Scott Long ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
But why does that even have to be an XFree86 issue? We already have fbdev drivers on Linux. It wouldn't be hard to add functionality to these drivers to get something simple like /dev/vblank that blocks until vertical sync. On Linux we already *have* video code for many common cards in the kernel. I'm not suggesting that XFree86 take on the responsibility for these drivers! What I'm saying is it doesn't seem like such a big deal to simply have *support* for a vblank mechanism. Leave the details of how it occurs up to a particular set of drivers. If people need vblank badly enough, the driver support will get written. You're right that other platforms might not support this so easily -- but so what? If people really need it, they'll write it. I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. This is a very simple change. If no driver support exists for vertical sync, the server can just politely ignore the request, and do the operation whenever it feels like it. This would at the very least provide a framework for individual driver writers to start working on a kernel interface. Scott Long On Fri, 1 Nov 2002 09:48:54 -0800 Ian Romanick [EMAIL PROTECTED] wrote: It's not impossible, but it does require a kernel driver. That makes it more than just a hairy problem for XFree86. Think about it. You'd likely need a *different* kernel module for every combination of hardware, operating system (aren't there some XFree86 supported systems that don't use loadable kernel modules?), and platform (i.e., X86 vs. Alpha vs. PowerPC, etc.). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Hooking onto Xserver
I think the easiest way to do what you are suggesting would be to run a proxy (your hook) that listens on the usual X socket (either TCP or UNIX). Then, run the X server on a non-standard port, and forward all the packets in both directions through your proxy. This assumes, first of all, that it's possible to run X on a non-standard port. I don't know how you would do this. Also, it would be inefficient if you only wanted to intercept X *requests*, since the X responses would have to pass back through your proxy on their way to the client. Could the Record extension somehow be used to do this? On Tue, 22 Oct 2002 01:20:05 -0700 (PDT) Anurag Palsule [EMAIL PROTECTED] wrote: Hello, Is it possible for me to write a wrapper or a hook to the Xserver,so that all the X calls, instead of going to Xserver, will land into my application and my application will inturn pass them to the X server for further processing. If yes, how ? thanks, Anurag __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Compiling XFree 4.2.1 with Gcc 2.96
I'm no Xpert on this, but it appears that someone forgot to put -fPIC in one of the makefiles? That would cause the _GLOBAL_OFFSET_TABLE linkage error... Scott On Fri, 20 Sep 2002 16:09:42 +0800 Jacky, Lau [EMAIL PROTECTED] wrote: Hi, I have tried to build XFree86-4.2.1 (I got a patch in ftp.xfree86.org), with Gcc 2.96. After I have done the make install, I try to start X, the following error occurs. Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 3 Elf_RelocateEntry() Unsupported relocation type 4 Elf_RelocateEntry() Unsupported relocation type 9 .. Symbol _GLOBAL_OFFSET_TABLE_ from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! Elf_RelocateEntry() Unsupported relocation type 10 .. Fatal server error : Caught signal 11. Server aborting What's the problem, gcc, or x or the patch, or anything else? My base distro is RH7.2 Zenith Lau ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Screen blanking with G550 + DVI
On Thu, 12 Sep 2002 08:20:21 +0100 (BST) Dr Andrew C Aitchison [EMAIL PROTECTED] wrote: Note that flat panels may note need as long a horizontal blanking time (fly-back) as CRTs. Does the DDC info in /vsr/log/XFree86.0.log suggest any modelines that the monitor likes ? Unfortunately XFree86 doesn't automatically use the modelines provided by DDC. Yeah, I did notice the DDC report in the config log. I tried the suggested DDC modeline with no positive results. Then again, I can't seem to remember whether I attempted that with or without the HAL driver. I'll give it another test tonight when I get home. Do you have any idea at all why the HAL module would screw things up? I have NEVER been able to get a screen while using HAL. A perusal of the mga driver source makes me think that all HAL is used for is to enable the second head and set the timings. Do you know if that is correct? Who should I direct that question to? Mark Vojkevich? Thanks for your help, Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]G550 + G400, overlay problems
Well, I can't even get the G550 to work alone, much less along with another card. I also see this screen distortion in dual-head mode. I believe it is due to the Matrox driver using incorrect timings on the second head, but I don't have the hours and hours to spend tweaking the modelines to try and get it working. And I still haven't found anyone who can explain to me why DVI output works without the HAL module. According to both the XFree86 and Matrox documentation, DVI shouldn't work at all without HAL. And when I do use HAL, neither the panel nor the CRT gets a good signal. Basically, if I do what the manual says, nothing works. Only by doing what the manual specifically says DOES NOT WORK do I actually get the thing to work. Oh, and in single-head mode, the display (DVI) blanks to black every couple of seconds. More often when a lot seems to be changing on the screen. I believe this is probably also related to incorrect timings. And yes, I've tried NoCompositeSync and it makes no difference whatsoever. If anyone out there has the G550 working, driving a DVI panel without this annoying blanking, can you please post your modelines to the list? I think having the correct modelines could be the ticket to getting dual-head to work with the HAL driver. Thanks, Scott Long 4) Using the Matrox drivers, both displays turn on but the secondary has some serious psychedelic visuals on it and the first has some mouse pointer issues. Personally, I'd rather use the XFree drivers if they can be made to work. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Capture to XPutImage
Based on my reading of the MIT-SHM documentation, I believe you might be able to do the following: 1. mmap your input buffer to any address you want. 2. call shmget() to obtain a shmid for the shared segment: shmid = shmget(IPC_PRIVATE, imageSize, IPC_CREAT | 0777); 3. Attach the shm segment to the mmap'd buffer by calling: shmaddr = shmat(shmid, buffer, 0); If the returned shmaddr != buffer, then the system wasn't able to attach the shared segment at the right address. You'll have to fall back to memcpy() in this case (after remembering to unmap/unattach the segment if necessary). 4. If shmaddr == buffer, you are ready to create the ShmImage: image = XShmCreateImage(display, visual, depth, format, NULL, shminfo, width, height); shminfo.shmid = shmid; shminfo.shmaddr = image-data = shmaddr; XShmAttach(display, shminfo); I *think* that's right... Scott On Thu, 5 Sep 2002 18:32:34 +1000 (EST) Brian W Grasby [EMAIL PROTECTED] wrote: Hello all, I'm writing a program that captures images from a bttv video capture card and processes them then outputs to the screen and i need real-time performance. Currently I'm using XImages to display on screen but i want to use MIT-SHM extension and XShmPutImage. My problem is that the data is coming from mmap()'ed buffers and i don't know how to get it into the XImage without doing memcopy. Currently I use XImage-data = buffer[i]; XPutImage(... Can i do this with SHM or can i mmap the same segment as i use for a SHM XImage? Or is it faster with memcopy? THanks Brian ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Dual Head + Fast 2D Graphics
On Tue, 30 Jul 2002 12:14:57 -0400 Randall Watt [EMAIL PROTECTED] wrote: The mga binary drivers are only necessary for DVI support and certain PowerDesk features. Other than that, the standard XFree86 supplied version of the mga driver should work just fine in either single or dualhead modes. Just wanted to clear up any misconceptions that the mga drivers are binary only. I don't get it. My G550 runs a DVI flatpanel just find without the HAL driver. Can someone please explain this? I *still* cannot get both heads to work with the G550. If I load the HAL driver, neither screen gets a good signal -- they both come up with the little blue box saying bad sync. If I don't load the HAL driver, I can get cloned screens, but the CRT gets a bad signal and looks wavy. I definitely cannot get Xinerama to work. When I get home later today I'll put my X logs and config files on a web server somewhere. But I'm giving up hope on the G550. If I can't get it working soon I'm gonna ditch it. Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Still no G550 satisfaction
I still haven't been able to get my Matrox G550 to drive both my Iiyama digital panel (DVI) and my Hitachi 771 (analog) at the same time -- Xinerama or otherwise. I have discovered some new things however. When running the digital panel at 1280x1024 depth 16, the CRT comes on then enters some strange mode (LED turns yellow) and sits. When I use a resolution lower that 1280x1024, the CRT comes up as a clone of the digital screen. Except that the picture is off-center and it wavers. To me, that sounds like the G550 is sending some incorrect video signal to the CRT. Driving it at a bizarre frequency, or something. When I run the digital panel at 1280x1024, maybe the signal gets *so* weird that the CRT can't cope, and just sits there blank? And this only works when I use Option NoHal on the mga driver. When I try to use HAL neither screen works -- they go blank then come up with the little blue box saying Bad signal -- check connection This is starting to get frustrating, because I've read of people getting almost the exact same setup to work perfectly. My motherboard is almost 4 years old. Could this be something strange with the motherboard/AGP controller? I'll be getting a new system soon, so maybe that will help. Does anyone have any ideas? Scott Long SwiftView, Inc. http://www.swiftview.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
