Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM***** Extracting a KeySym from an action routine)
Alexander Stohr wrote: a moderated spam filter would be nicest, but this means that someone has permanent duty for letting falsely blocked mail pass, This is not quite true. I can envision a system that automatically quarantines (rather than discarding) suspected spam. It would then send e-mail back to the sender telling them how to take their message out of the quarantine area and have it delivered to the list (presumably by entering a one-time password on a web site). A message that was stuck in quarantine for more than a few days would automatically be removed. As spammers typically do not bother to use valid return addresses, this technique should be sufficient to tell whether a real person has sent the e-mail, or whether it was created by a a bulk mailer. While still not perfect, I'd image this approach to eliminate most spam without inconveniencing subscribers too much. Markus -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 dies early without error
Matthieu Herrb wrote: Do the PAX patches allow mprotect() calls to make the allocated pages executable ? The XFree86 ELF loader currently miss a few mprotect() calls, but I've a patch that adds the missing calls and make the loader happy again on OpenBSD architectures that have non-executable heap now. It should work too with PAX if it implements mprotect(). PAX is very flexible this way and allows for the user to configure whether mprotect() can be used to change permissions on pages. So, yes, a patch that added all the missing mprotect() calls would definitly make the code more friendly towards environments such as PAX. Markus -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: X 4.2.x + TNT + ATI All-In-Wonder 128 = hard freeze - it's something else
The motherboard sensors tend to be pretty slow and only give you an average value. Unfortunately, long before you see hardware failing due to low voltage, you'll run into problems with transients. Short of hooking up some expensive test equipment (a oscilloscope would work), there isn't much you can do to test for these -- and power supply manufacturers don't typically tell you all the specs that you need to know. As a rule of thumb, if you buy a power supply that has generous extra ampere ratings on all of the different voltage lines (e.g. 3.3V, 5V, 12V, and the negative ones), chances are you'll get something that will be able to avoid transients, but even then there are no real guarantees. For a system with one or two fast CPUs (1GHz and above) and a modern AGP graphics card, you will probably want to get a PSU that is rated in excess of 300W (450W or so is probably a good bet). If you can buy a reputable brand-name product, you might want to consider that option -- and even after all this, you might still have bad luck and end up with a PSU that just doesn't work with your system. Markus P.S.: BTW, if your graphics card has a connector that allows you to supply additional power directly to it rather than going through the AGP bus, then make sure you take advantage of this. Modern graphics card put quite some load on the system and not all motherboards can supply this much current over the AGP bus itself. Xavier Bestel wrote: Le mer 11/09/2002 à 21:18, Alexander Stohr a écrit : He should think about the power supply... The integrated health status sensors of my motherboard tell me voltages are Ok ... can I trust them ? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Make Install problems...
Do you have a symbolic link in /usr/lib/libncurses.so pointing to /lib/libncurses.so.5? The file without the version number is the one that is picked up at link time, whereas the ones with the version numbers get picked up at runtime. If you don't have the neccessary symbolic link, that might be a sign that you also don't have the rest of the development files. As I don't know which distribution you have, I can't tell you how to fix this (on Debian, you'd type apt-get install libncurses5-dev) Markus [EMAIL PROTECTED] wrote: I put this on the newbie list, but since it sees about as much traffic as an ice-cream shop in a blizzard...I thought Id try here: I was having problems with the rpms for my distro,so I decided to give the source a try...make World went well after I installed the bison and flex that I didnt see needed in the docs,anyhow it stalls on make install with: /usr/bin/ld : cannot find -lncurses so I check and I currently have in /lib: libncurses.so.1 libncurses.so.1.9.9e libncurses.so.3 libncurses.so.3.0 libncurses.so.4 libncurses.so.4.2 libncurses.so.5 libncurses.so.5.0 libncurses.so.5.2 all of these point to the libncurses.so.5.2,and so I look back through the def and cf files and host.def has the some distros dont have termcap, the #define termcap blah blah -lncurses,so I comment it out,because I have libtermcap.so.2 and .so.2.0.8 and it still hangs in the same spot with the cannot find -lncurses..what am I missing? -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]zoom
You can probably do something with either XSendEvent() or with XTestFakeButtonEvent(). If I was going to try doing this, I'd probably take a look at the source code for x2x. Markus sjb wrote: sjb wrote: man XF86VidModeSwitchMode Ahh .. that would appear to do the trick! OK .. I now have a working Zoom button. Thanks for the pointer! Another question .. is it possible to send a middle mouse button click to the server? My Vaio is constructed so that you can use it standing up, with the two mouse buttons at the top left of the keyboard. Sadly, it's nigh on impossible to press them both simultaneously with your thumb, which makes pasting text a bit problematic. TIA sjb ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Recommendations for card with DVI support (1600x1200)
As promised, here is my summary of what I had to do to make this work. Dr Andrew C Aitchison wrote: I don't know whether it will do 1600x1200, but I am driving a 1600x1024 panel from the DVI interface on my G550. Thank you, this was the missing part of the puzzle. Your suggestion about trying to make it work anyway, prompted me to ask the same question on Matrox' support board. I learnt that DVI interfaces work very similar to conventional RGB interfaces and include a component that is equivalent to the RAMDAC on an analog card (obviously, this circuit doesn't do any digital-to-anlog conversion, but it does handle the pushing of data from the video buffer to the monitor). As with RAMDACs there is a maximum valid pixel clock. And whereas the maxium pixel clock for the analog RAMDAC is 360MHz, the limit for its digital counterpart is only 112MHz. Normally, this wouldn't be enough to drive a display at 1600x1200. Experiments show, that it is possible to overclock beyond 112MHz up to about 146MHz. Of course, this might have detrimental effects on the longevity of the graphics card and a different solution would be preferable. After I realized that LCD panels don't really need very high vertical refresh rates, as each pixel acts as a memory cell that can hold its value until it is rewritten, and after I realized that there is no such thing as an electron beam retrace, I decided to play with the mode line values. Here is a mode line that stays within the specs of both the monitor and the graphics card. It keeps the pixel clock at 112MHz and displays 1600x1200@56Hz (67kHz): 1600x1200 112.00 1600 1608 1616 1640 1200 1201 1204 1210 +hsync +vsync I noticed that in true color mode, this mode line leaves relatively little time for the graphics card to write to video memory while the picture is sent to the monitor, and there are visible artefacts if there is a lot of graphics activity. Depending on how adventurous you feel, it is possible to increase the last two horizontal timing parameters (1616 and 1640 in this case) by a little bit and then compensate by overclocking the graphics card (increase from 112.00 to some slightly bigger value). xvidtune comes in very handy when playing with these values. I use CVS XFree86 (I'm not sure whether 4.2 would work) with the XFree86 supplied mga driver, but I have to (or did last time I checked) use the Matrox supplied mga_hal_drv.o. I have heard that other people can only get the DVI interface to driver their panels if the *don't* use mga_hal_drv.o I had success driving the G550 card with the copy of XFree 4.1 that ships with Debian/unstable, but I did have to install Matrox' binary driver modules. Without doing that, the graphics chipset would not be recognized. Unfortunately, I now see lots of undefined symbols whenever I try to make the card run in a dual-headed configuration. I guess, I will have to compile my own binaries after all (which gets a little tricky because of all the patches that Debian applies; but I am sure, I will get that worked out over the next few days). Thanks for everybody's help with this issue, Markus ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Recommendations for card with DVI support (1600x1200)
After reading the mailing list archive for the last half year or so, I am now even more confused than before. I am looking for a graphics card that allows me to drive my Dell flat panel display at 1600x1200 using the DVI interface. Apparently, my initial choice of a Matrox G550 was a poor decision as this card cannot drive DVI at more than 1280x1024 (I now need to find out what my vendor's return policy is...) Ideally, I am looking for a solution that is supported by open source X11 drivers, but I am willing to settle for closed source ones if that is my only option at this time. While Debian Linux only ships XF86 4.1.0, I wouldn't have any problems with compiling a CVS snapshot and/or applying external patches. I don't require 3D acceleration, but would prefer rock-solid 2D operation. As the screen was expensive enough, a card in the $100 (or less) range would be preferable. If the card can simultaneously drive a second analog monitor, that would be a bonus, but I guess I can always plug in an old PCI graphics card. If I receive multiple different suggestions, I promise to write a summary on my experiences once I get everything to work. I would guess that with the price for large LCD panels dropping, this might turn into an FAQ. Markus P.S.: I earlier tried sending this e-mail using a slightly different return address; it is now pending approval by the list administrator. So, if you eventually see a duplicate post, then I would like to apologize for it. -- Markus Gutschke 3637 Fillmore Street #106 San Francisco, CA 94123-1600 +1-415-567-8449 [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
