CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 03:57:06 Log message: 405. Don't call FBIOPAN_DISPLAY ioctl with arguments that will cause a confusing if harmless error; make an fbdevhw internal function static to fix a warning. (Michel Dänzer) Modified files: xc/programs/Xserver/hw/xfree86/fbdevhw/: fbdevhw.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.32 +7 -2 xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c 3.2828+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 04:34:57 Log message: 406. Added big5hkscs encoding to font encoding files (Bugzilla #575, Jungshik Shin). Modified files: xc/fonts/encodings/large/: Imakefile xc/programs/Xserver/hw/xfree86/: CHANGELOG Added files: xc/fonts/encodings/large/: big5hkscs-0.enc Revision ChangesPath 1.4 +3 -2 xc/fonts/encodings/large/Imakefile 3.2829+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: xf-4_3-branch)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 04:47:26 Log message: 1000. Fixed a crash when _XIMProtoOpenIM(), hich is called through XOpenIM() API when protocol IM is being set up, fails (Bugzilla #618, Hisashi MIYASHITA). Modified files: xc/lib/X11/: Tag: xf-4_3-branch imDefIm.c xc/programs/Xserver/hw/xfree86/: Tag: xf-4_3-branch CHANGELOG Revision ChangesPath 1.11.2.1 +1 -0 xc/lib/X11/imDefIm.c 3.2588.2.25 +3 -0 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: xf-4_3-branch)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 05:17:44 Log message: 1001. Don't call FBIOPAN_DISPLAY ioctl with arguments that will cause a confusing if harmless error (Michel Dänzer) Modified files: xc/programs/Xserver/hw/xfree86/fbdevhw/: Tag: xf-4_3-branch fbdevhw.c xc/programs/Xserver/hw/xfree86/: Tag: xf-4_3-branch CHANGELOG Revision ChangesPath 1.30.2.1 +6 -1 xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c 3.2588.2.26 +3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 07:29:37 Log message: Fix for another, different version of Clevo L285/287 Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init.h init301.c init301.h sis.h sis310_accel.c sis310_accel.h sis_driver.c sis_driver.h vstruct.h Revision ChangesPath 1.15 +9 -41 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.17 +21 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.23 +73 -53xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.19 +7 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.h 1.46 +5 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.11 +243 -90 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.9 +29 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.109 +29 -24xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.15 +10 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.h 1.13 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/vstruct.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 08:22:27 Log message: Warning fixes Modified files: xc/programs/Xserver/hw/xfree86/drivers/glint/: glint_driver.c Revision ChangesPath 1.159 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/glint/glint_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 08:38:40 Log message: Build fixes Modified files: xc/lib/xtrans/: Xtransdnet.c Xtranslcl.c Xtransos2.c Xtranstli.c Revision ChangesPath 3.8 +2 -2 xc/lib/xtrans/Xtransdnet.c 3.41 +2 -2 xc/lib/xtrans/Xtranslcl.c 3.10 +2 -2 xc/lib/xtrans/Xtransos2.c 3.13 +3 -3 xc/lib/xtrans/Xtranstli.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 08:42:11 Log message: Warning fixes Modified files: xc/programs/xev/: xev.c Revision ChangesPath 1.11 +3 -3 xc/programs/xev/xev.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 09:38:04 Log message: Fix dualhead mode related crash (VRAM queue) Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis.h sis310_accel.c sis_driver.c Revision ChangesPath 1.47 +5 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.12 +63 -38xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.110 +15 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 09:49:35 Log message: Fix LVDSHL option Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init301.c sis310_accel.c Revision ChangesPath 1.24 +16 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.13 +0 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 12:00:36 Log message: Typo Modified files: xc/programs/Xserver/hw/xfree86/os-support/sunos/: sun_kbdEv.c Revision ChangesPath 1.5 +2 -2 xc/programs/Xserver/hw/xfree86/os-support/sunos/sun_kbdEv.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 13:40:25 Log message: Further fix for (second version of) Clevo L285/287 Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init301.c initdef.h sis.h sis310_accel.c sis_dac.c sis_driver.c sis_vb.c sis_vga.c vgatypes.h Revision ChangesPath 1.16 +24 -21xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.25 +31 -12xc/programs/Xserver/hw/xfree86/drivers/sis/init301.c 1.17 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/initdef.h 1.48 +4 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.14 +0 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.39 +8 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dac.c 1.111 +33 -15xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.16 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vb.c 1.25 +16 -11xc/programs/Xserver/hw/xfree86/drivers/sis/sis_vga.c 1.9 +1 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/vgatypes.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: cvs:drivers/via/via_driver.c: problem with Virtual
death writes: The Savage driver, from which I believe this driver was derived, copies pScrn- display-virtual[XY] to pScrn-virtual[XY] a page or so above the call to xf86ValidateModes. Is that not happening here? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. Well, i hadnt looked as far, i just saw it done like this in vesa.c and i810_driver.c. Also, i just used a few xf86DrvMsgs to tell me the values of pScrn-VirtualX/Y throughout PreInit. In both vesa and via_driver, they were 0 before xf86ValidateModes and set (properly in case of vesa and to actual resolution in via) after. This made me assume that pScrn-display-virtualX/Y would contain the values of the Display subsection, the values requested through the config and that xf86ValidateModes would validate this (duh.) and, if approved of, place those values in the toplevel pScrn. Yes, this should be done in xf86ValidateModes() and in fact the via driver doesn't copy it before calling it. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XInput: The device type in XListInputDevices comes up again...
First of all: Since I am new to this list (this is my first post), I do
hope that I'll be able to avoid the major pitfalls of what is considered
bad behaviour on this particular mailing list... :-)
Since I am currently writing a device manager for a cross-platform
windowing toolkit under OpenGL and right now working on the X port of the
toolkit, the behaviour of the device management is very important to me.
On the 26th of June, Egbert Eich concluded a discussion on the fact that
the type and name field of the _XDeviceInfo struct returned by
XListInputDevices contain information which is inconsistent with what the
documentation says by writing (in Re: XInput: device name in
XListInputDevices):
Maybe this is the time to table all issues [with current extended input
management] we can come up with so we can find solutions.
In the meantime I will modify the input drivers to return the id's
predefined types in the type field and the product names in the
'name' field.
As far as I can see, this discussion on the behaviour of the extended
input devices promptly died. I don't really mind if it works the way
Egbert wants to make it work because it would then neatly cover what I
need for my toolkit port - I would say, however, that the current extended
device management as a whole seems rather unsophisticated.
What *is* important, though, is that the -type field of the _XDeviceInfo
struct is made to contain something usable. As I understand it, Egbert
wants to make the -type field contain an atom so that the following
quasi-code would make sense:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
b) When can we expect this fix to have been implemented? Is there already
a patch for it or will it surface in some distant full release of the X11?
Thanks in advance,
Claus Matthiesen
PS.
Egberts original full conclusion can be found at:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01879.html
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
RENDER question
Since I recently found out that SiS hardware _does_ support per-pixel alpha-blended bitblits, I could finish the (yet disabled) render acceleration. The only problem I encountered: The functions that I provide (SetupFor/SubsequentCPUToScreen[Alpha]Texture) are never called as it seems How come? Shouldn't AA text be drawn using these functions? Is there any test program for this? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Tue, 26 Aug 2003, Egbert Eich wrote: John Dennis writes: I just received information from HP (thank you Bjorn Helgaas) that the memory attribute does not direct access between RAM and IO, I was in error. But what is critical is that the EFI MDT (Memory Descriptor Table?) which is set up at boot time is the arbiter of which memory attributes are used for various memory regions. User space mappings that try to force cached vs. non-cached accesses are inappropriate, its not their decision, rather it must be consistent with the EFI table which is set up at boot time. There is a kernel patch that ignores the user request for cached vs. uncached mappings and instead (indirectly) consults the EFI MDT such that the memory attribute field in the TLB is consistent with how that memory is referenced in the system, as determined by the firmware (EFI). Beta RH kernel's were missing this patch that had been present in earlier kernels. Bjorn tells me that with the patch applied no changes need to be made to X for proper operation and that the patch is in the upstream kernel sources. thanks for following up on this. Does this patch also take care of the SlowCopy() access to the VGA framebuffer memory at 0xa? FYI, the patch follows for those interested, note that O_SYNC is no longer used as a trigger for non-cached access. I have dropped the O_SYNC from open(/dev/mem) for all platforms a while ago. However on IA64 we pass MAP_NONCACHED or MAP_WRITECOMBINED to mmap() depending on the type of region. I assume we don't need this any more, either. Now, one question remains: does the EFI MDT distingquish between (cacheable) framebuffer memory and MMIO registers which should neither be cached nor set WC? Uncached framebuffer memory doesn't cause failures but gives a huge performance penalty. Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
Now, you have the name field. What do you put in there? Lots of people
put in the name of the device driver. E.g., aiptek or wacom stylus.
This doesn't help the USER, because that's not the identifier he used in
the XF86Config file.
Now, I personally have reasons for wanting to know that a given device
is supported by my device driver: I have a client/driver API layered on
top of the FeedbackControl API. What do I do? Assume because I support a
tablet, that all tablet's found are obviously controlled by my driver
(wrong!) Assume that if I find a XI_CURSOR, it's obviously something
that belongs to my driver? (wrong! the user could have two tablets, one
of which is a wacom...) Do something to the name field to pass three
pieces of information? (e.g., you used the identifier Leopold for the
stylus pseudo device driver, that's controlled by the aiptek driver, so
perhaps Leopod (aiptek:cursor)? That's not real user-friendly. Does
that mean that your app should know to only display the first word of
the name field? Ugh...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
What I think is needed, but I don't know if this is sufficient: a device
type and sub-type, which are both Atoms and codified so a user app
actually has a chance of understanding what the string sequence means.
But is a single sub-type sufficient? I don't know. For example, Data
Gloves: is it important to know that it's left or right-handed? Can
those have styluses, too? Then that's two sub-types. Is it possible to
have more?
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
I just wanted to follow up with this for those who are maintaining the memory mapping code in the CVS tree, this is linux ia64 specific and possibly HP ZX1 specific. As of today this is best information I have and wanted to share it. Originally the MAP_NONCACHED passed to mmap caused non-cached access. That was deprecated in favor of the O_SYNC flag passed to the open of /dev/mem. As of linux kernels 2.5.xx or those which have been patched, these flags are both deprecated and ignored. At some point os-support/linux/lnx_video.c should clean up the use of these flags. There are a few other places in the tree these flags are used as well. However, for the time being the use of these flags should remain as people may be running on kernels without the automatic detection of the caching attribute. The critical issue is that caching attribute the kernel sets in the TLB must match the EFI (firmware) setup. It has been a fortunate consequence that when XFree86 passed the non-caching flags it was for memory regions that EFI had configured to be non-caching and no problem was observed, the non-caching flag caused the kernel to set the TLB correctly. For kernels that ignore the flag it will still set the TLB correctly via an automatic mechanism. EFI will have created non-cached mappings with the HP ZX1 chipset for ALL PCI memory regions since the ZX1 only supports non-cached on IO. Anytime in the XServer when MMIO was specified as a mapping flag the ia64 code would have requested non-cached, this is done for all register mappings and the VGA framebuffer (because write combining was avoided on banked memory). If the FAMEBUFFER flag is passed then write combining is selected instead of non-cached, but the framebuffer should have also been set up by the firmware as non-cached. I would expect this to have caused an inconsistency between the TLB entry and the ZX1 chipset possibly leading to MCA's but this has not been observed, so I can't explain that one. The only other example I have heard of where XFree86 was requesting a cached or non-cached mapping which was not consistent with EFI is the mapping of ROM BIOS when using the ROM base address register in the PCI config. EFI treats that memory as non-cached because its PCI and the non-cached flag was not passed in xf86ReadBIOS. ROM BIOS cached reads to the standard video rom address 0xC were fine because its a shadow image in RAM which is cached. So far I can only find source code that passes 0xC to xf86ReadBIOS, but that does not mean there isn't code lurking somewhere that uses the PCI ROM BAR. The MAP_WRITECOMBINED flag passed to mmap is now also deprecated in Linux as of 2.4.19 for two reasons, its lack of support on most ia64 platforms and because of memory attribute aliasing problems that originally caused the MAP_NONCACHED and O_SYNC flags to be removed. The flag can still be specified, but will be ignorned. Note that all ia64 GARTs are now run in choerent mode, so there is no need for write combining. John ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Tue, 2003-08-26 at 10:22, Marc Aurele La France wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. My understanding (albeit limited) from correspondence with HP is that it is the chipset that determines this. On current HP ia64 they use the ZX1 chipset which only does non-cached access on PCI. Thus if firmware knows there is a ZX1 chipset it knows how the memory region will be handled. Apparently EFI also seems to know about GARTs. Intel boxes used a different chipset but share EFI and the kernel code so it should be behave the same. I'm leery of misinterpreting some of the correspondence so is the actual text from some of it, if you draw different conclusions let me know. John What had been confusing at this end is the notion that ROM by John definition can never be incoherent, therefore cached John vs. non-cached should be irrelevant. HP Ah, I see that point. The problem in this case is that the HP chipset may support different types of access to different HP regions. (That's part of what the EFI MDT tells you.) The ZX1 HP chipset doesn't support cacheable access to any MMIO space, HP regardless of whether that space happens to contain RAM, ROM, HP device CSRs, etc. John The problem if I understand correctly is that the access was not John consistent with the EFI table defining what the memory attribute John needed to be. Bottom line, its EFI that determines cachability, John not a prori knowledge of the memory characteristics being John mapped. HP Right. And the underlying chipset determines what goes in the EFI HP table. - John This made me think about the MAP_WRITECOMBINED flag passed to John mmap. The current scheme has EFI responsible for determining the John cached vs. non-cached memory attribute, the user should not be John specifying such a memory attribute. Write combining or write John coalescing is one variant of a non-cached memory attribute on John ia64 that is used for frame buffers. My understanding is that John EFI will be ignorant of this memory attribute and the John MAP_WRITECOMBINED remains a valid flag to pass. I also assume John that passing this flag replaces an ma value of 4 (uncached) with John 6 (uncached write coalescing) and that such a replacement, John outside the scope of the EFI MDT is valid because both share the John uncached attribute. Correct? HP The EFI MDT does have a bit for WC, but I don't know of any ia64 HP platform that sets it. I removed support for MAP_WRITECOMBINED in HP the 2.4.19 patch because we don't have a good way of using it HP safely. (Even if there were an ia64 platform that claimed to HP support it, we'd have to be very careful to avoid the attribute HP aliasing problem. The fact that kernel identity mappings don't HP have page tables and are inserted in 64Mb (or maybe 16Mb) chunks HP means that we'd have to somehow ensure that a 64Mb chunk that HP contained a WC mapping could never also be mapped WB.) HP From the user side, MAP_WRITECOMBINED can still be specified; we HP just ignore it in the kernel. This used to be used for AGP, but HP all ia64 GARTs are now run in coherent mode, so there's no need HP for WC. HP It is possible for multiple attributes to be supported, so it's HP conceivable that we could look at user requests for special HP mappings. For example, the i2000 supports both UC and WB mappings HP of main memory. But at the moment, I don't think there's an HP actual need for such a feature, and the fact that we don't have HP kernel page tables would complicate adding it. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
Sorry for replying to my own post: Since I have found only one application triggering calls to the accelerated RENDER functions (openoffice), I wonder under what circumstances these functions are called as regards anti-aliased text? Why isn't for example Qt (which I use in version 3.1.1 here) or Mozilla (1.4, Debian's xft-enabled version) triggering these functions? Thomas Winischhofer wrote: Since I recently found out that SiS hardware _does_ support per-pixel alpha-blended bitblits, I could finish the (yet disabled) render acceleration. The only problem I encountered: The functions that I provide (SetupFor/SubsequentCPUToScreen[Alpha]Texture) are never called as it seems How come? Shouldn't AA text be drawn using these functions? Is there any test program for this? -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
Marc Aurele La France writes: On Tue, 26 Aug 2003, Egbert Eich wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. How that is done is in fact an interesting question. Maybe someone with good contacts to HP could inquire on this. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Tue, 2003-08-26 at 13:40, Egbert Eich wrote: Marc Aurele La France writes: On Tue, 26 Aug 2003, Egbert Eich wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. How that is done is in fact an interesting question. Maybe someone with good contacts to HP could inquire on this. I will confess my understanding is weak when it comes to low level bus interactions, but I'm learning more eveytime I have to tackle these issues ;-) Correct me if I'm wrong, but I thought things like caching and write-combining are not properties of the PCI device, rather they are properties of the memory system upstream of the PCI device, e.g. bridges, memory controllers, and the MMU in the CPU. The PCI configuration does provide various pieces of information which help determine how the device can be accessed, e.g. pre-fetch, latency, cache line size etc. All of this is available to firmware. Wouldn't all this be sufficient for firmware to make the right decisions? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
The term 'tablet' is inconclusive. XI_TABLET should not be used for such
tablets. The tablet itself is not really the device as far as XI is
concerned. It does not provide coordinates/keys/buttons itself. That
would be like saying your mousepad is your input device. Instead each
pen should be considered a different input device and we may need to
extend the list of predefined types to accomodate those.
I don't really know if it is at all importand that different pens are
related to a specific tablet. If it is we need a way to 'group'
certain devices together.
Now, you have the name field. What do you put in there? Lots of people
put in the name of the device driver. E.g., aiptek or wacom stylus.
This doesn't help the USER, because that's not the identifier he used in
the XF86Config file.
Now, I personally have reasons for wanting to know that a given device
is supported by my device driver: I have a client/driver API layered on
top of the FeedbackControl API. What do I do? Assume because I support a
tablet, that all tablet's found are obviously controlled by my driver
(wrong!) Assume that if I find a XI_CURSOR, it's obviously something
that belongs to my driver? (wrong! the user could have two tablets, one
of which is a wacom...) Do something to the name field to pass three
pieces of information? (e.g., you used the identifier Leopold for the
stylus pseudo device driver, that's controlled by the aiptek driver, so
perhaps Leopod (aiptek:cursor)? That's not real user-friendly. Does
that mean that your app should know to only display the first word of
the name field? Ugh...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
The device driver is completely irrelevant to the application.
Why should the application know that? The application may want
to know a vendor string and an ID to know more about the properties
of an individual device (some pens supply pressure or angular data
some don't).
What I think is needed, but I don't know if this is sufficient: a device
type and sub-type, which are both Atoms and codified so a user app
actually has a chance of understanding what the string sequence means.
But is a single sub-type sufficient? I don't know. For example, Data
Gloves: is it important to know that it's left or right-handed? Can
those have styluses, too? Then that's two sub-types. Is it possible to
have more?
These would be properties. Properties can be accumulated, types are
exclusive. I don't know if we can manage to characterize all device
properties completely and if this is desirable. In many cases we may
just be able to supply coordinates and the application needs to be
configured to know what to do with these.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote:
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Sure, albeit dangerously. They had best not be making decisions based on
what's returned in the string...
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
The term 'tablet' is inconclusive. XI_TABLET should not be used for such
tablets.
I can argue both for and against that statement. Don't forget, the
application using the API possibly will want to indicate the pen device
#1, #2 and mouse device #3 are all related to a tablet, in the spirit of
user-friendliness.
The tablet itself is not really the device as far as XI is
concerned. It does not provide coordinates/keys/buttons itself.
Yes it is but no it isn't. Remember, there is a single cable running
from the tablet to the USB port. Which means, if it's hotplug disabled,
somebody has to understand that all these devices should be disabled...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
The device driver is completely irrelevant to the application.
Why should the application know that? The application may want
to know a vendor string and an ID to know more about the properties
of an individual device (some pens supply pressure or angular data
some don't).
Most do not. Mine does, because it's the client side of that
client/driver API I mentioned: it has to know which drivers support my
extended API. But I don't expect to find that kind of info in the
deviceInfo struct...
These would be properties. Properties can be accumulated, types are
exclusive. I don't know if we can manage to characterize all device
properties completely and if this is desirable. In many cases we may
just be able to supply coordinates and the application needs to be
configured to know what to do with these.
A heirarchical system is the way to go.
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [I18n] crash in _XimThaiCloseIM
On Fri, 1 Aug 2003, Jungshik Shin wrote: I'm wondering if anyone has an idea of a possible cause of crash in _XimThaiCloseIM() apparently triggered by Flash plugin for Mozilla (Konqueror also has a similar problem). Flash plugin can work around this, but the crash is occuring in _XimThaiCloseIM() http://bugs.xfree86.org/show_bug.cgi?id=546 Related Mozilla bugs are listed at http://bugzilla.mozilla.org/show_bug.cgi?id=211213 Glad to report that Miyashita-san's (a lot of thanks goes to him) patch for bug 618 (http://bugs.xfree86.org/show_bug.cgi?id=618) fixed the problem. This bug made it all but impossible to use Mozilla/Konqueror with flash plugins for surfing Korean (actually any page with flash-animations, but Koreans seem to be particularly fond of putting flash animations in every page they make, which I'm not so proud of ;-p)) pages (one of reasons I often resort to w3m-m17n). A work around was to launch Mozilla/Konqueror under C locale, in which case I couldn't use XIM. Anyway, it'd be nice if this patch (for bug 618) could be picked up by Linux distribution builders soon. Jungshik ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
RE: [I18n] Re: Some thoughts on XKB symbols
Nicolas Mailhot wrote: The problem is - most users wouldn't care less if there was a single clean layout per language or group of languages (we wouldn't Yes, but that requires some standardisation effort. be in this mess for example if there was a single latin layout and countries hadn't had to invent variations on a common core to accommodate the glyphs qwerty forgot). [glyphs - characters] Ahem. There are quite a lot of 'latin letters that qwerty forgot', and some are used quite frequently in some languages, and there deserve their own keys, even on levels 12. For punctuation and symbols, I agree with you more. ... The per-country optimisations are largely bogus - typewriter leftovers weight much more than what one could win by taking into account one glyph is used marginally more in a country than in its neighbours (and That may be, but that argument does not take into account that some frequent letters in one langauge's orthography may be rather hard to type on a keyboard for another language; and the number of keys on a keyboard is rather limited. Depending on how one wishes to count, there is in the order of 1000 Latin letters. Many of them are composable from a base letter + diacritic (or several diacritics), but that hold for far from all of the non-ASCII ones. /kent k ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
RE: [I18n] Re: Some thoughts on XKB symbols
Le mar 26/08/2003 à 16:09, Kent Karlsson a écrit : Nicolas Mailhot wrote: The problem is - most users wouldn't care less if there was a single clean layout per language or group of languages (we wouldn't Yes, but that requires some standardisation effort. be in this mess for example if there was a single latin layout and countries hadn't had to invent variations on a common core to accommodate the glyphs qwerty forgot). [glyphs - characters] Ahem. There are quite a lot of 'latin letters that qwerty forgot', and some are used quite frequently in some languages, and there deserve their own keys, even on levels 12. For punctuation and symbols, I agree with you more. Sure. When countries can not even agree on the dot/number location, what should we expect ? There is room for some serious merging and standardisation - anyone who had to switch between layouts knows it. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
[I18n] TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [XFree86] TV-out on radeon 9000
Thanks for the answer. I googled my little head off looking for an answer, including the 4.3 release notes for the radeon driver and searches across this list. It would have been nice if somewhere it said that tv-out wasn't supported by the radeon driver :( I switched to the vesa driver and now it works but it really fuzzy (unfocused) -- even large fonts are unreadable. What's the modeline for the highest resolution setting that an plain old NTSC-M TV will support? Alex Deucher wrote: Xfree86 does not offically support TV-out yet on radeon. I've heard some people in the GATOS project have gotten it to work so you may inquire there. http://gatos.sf.net Entering an NTSC modeline will produce an NTSC signal on the VGA port. The TV-out put has a separate DAC to drive it. Alex -- I am at wits end. I have tried and tried to get the s-video out of my radeon 9000 to work in X. My computer is a home-theatre pc, located in my entertainment cabinet, and will only ever be using the s-video out (never vga). The only cable connected to the radeon card is an s-video cable to my plain old NTSC-M TV. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] error log attached - cannot access X server
On Mon, 25 Aug 2003, Krys Binczyk wrote: http://www.google.com/search?hl=enie=ISO-8859-1q=could+not+open+default+font+%27fixed%27%0A MARk. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] extract (gnu-tar) segfaults on debian SID
It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? W ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Still messin around with ModeLines...
On Tue, Aug 26, 2003 at 12:20:24AM +0200, Bonny wrote: In data Mon, 25 Aug 2003 14:43:16 -0400 David Dawes [EMAIL PROTECTED] scriveva: The name can be anything you like. In fact if you want to eliminate any doubt that a custom mode you specify is the one getting used, give it an unusual name :-). That makes it easy to check for it in the XFree86 log file. We definitely need to see that log file to see what's going on here. Here some info: [EMAIL PROTECTED] log]$ cat XFree86.0.log|grep SOG (II) NVIDIA(0): Not using mode SOG (hsync out of range) This means that the SOG mode has a horizontal sync rate higher than you've specified for your monitor. The monitor section you posted before was: Section Monitor Identifier Monitor0 VendorName NORTEK ModelNameKENDO1511 # DisplaySize 305230 # HorizSync31.0 - 60.0 # VertRefresh 56.0 - 75.0 HorizSync30.0 - 80.0 VertRefresh 56.0 - 100.0 Option dpms ModeLineSOG 94.116 1024 1061 1198 1364 768 770 783 814 -HSync -VSync EndSection The hsync for your mode is 94166/1364 = 69.0. I'd expect the hsync out of range result for the 31.0 - 60.0 HorizSync line, but not for the 30.0 - 80.0 line. Without all of the information (matching config and log files), we still have to make guesses. What do you mean? Or do you need some more excerpts from my logfile? Yes. What you've shown so far isn't consistent with the Monitor section you posted. It's easier to send the whole file than to figure out every line that might be relevant :-). David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
On Tue, Aug 26, 2003 at 02:24:23AM +0200, wim delvaux wrote: It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? We occasionally see reports like this, but I don't recall if the reason for the problem was found. The extract binary for Linux is statically linked. Maybe we need dynamically linked versions? Which binary set did you download? (ie, what did 'sh Xinstall.sh -check' report?) David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Boot camp
I would like to report an error I received from my boot up. IO fatal error 104 (0 requests)0... I would appreciate a response. Thank you for your time. _Jason -- __ http://www.AsianAvenue.com/ - Click into Asian America Download to your desktop : POP3 access for US$19.95/yr Powered by Outblaze ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Resolution
Hi, My name is Fábio, and I have a display board of Trident TGUI 9685, I would like to know how resolution i coul use and how could I centralize the graphics pixels, etc
[XFree86] server crash
i have recently installed rhl9 on my pentiumIII,866 MHZ,128MB SRAM,samsung samtron monitor,vintron motherboard 810,segate 40gb hard drive.after successfully booting 2-3 times after installations ,now i can't get my xserver started.the full server output is as follows XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2)Release Date: 27 February 2003X Protocol Version 11, Revision 0, Release 6.6Build Operating System: Linux 2.4.20-3bigmem i686 [ELF] Build Date: 27 February 2003Build Host: porky.devel.redhat.com Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version.Module Loader presentOS Kernel: Linux version 2.4.20-8 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 Markers: (--) probed, (**) from config file, (==) default setting,(++) from command line, (!!) notice, (II) informational,(WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: "/var/log/XFree86.0.log", Time: Tue Aug 26 08:08:02 2003(==) Using config file: "/etc/X11/XF86Config"(==) ServerLayout "Default Layout"(**) |--Screen "Screen0" (0)(**) | |--Monitor "Monitor0"(**) | |--Device "Videocard0"(**) |--Input Device "Mouse0"(**) |--Input Device "Keyboard0"(**) Option "XkbRules" "xfr! ee86"(**) XKB: rules: "xfree86"(**) Option "XkbModel" "pc105"(**) XKB: model: "pc105"(**) Option "XkbLayout" "us"(**) XKB: layout: "us"(==) Keyboard: CustomKeycode disabled(**) |--Input Device "DevInputMice"(**) FontPath set to "unix/:7100"(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"(==) ModulePath set to "/usr/X11R6/lib/modules"(++) using VT number 7(II) Open APM successful(II) Module ABI versions:XFree86 ANSI C Emulation: 0.2XFree86 Video Driver: 0.6XFree86 XInput driver : 0.4XFree86 Server Extension : 0.2XFree86 Font Renderer : 0.4 (II) Loader running on linux(II) LoadModule: "bitmap"(WW) Warning, couldn't open module bitmap(II) UnloadModule: "bitmap"(EE) Failed to load module "bitmap" (module does not exist, 0)(II) LoadModule: "pcidata"(WW) Warning, couldn't open module pcidata(II) UnloadModule: "pcidata"(EE) Failed to load module "pcidata" (module does not exist, 0)Fatal server error:Unable to load required base modules, Exiting... please go through the problem and help me at [EMAIL PROTECTED]. thanks Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.comBuy The Best In BOOKS at http://www.bestsellers.indiatimes.comBid for Air Tickets on Air Sahara Flights at Prices Lower Than Before. Just log on to http://airsahara.indiatimes.com and Bid Now !
[XFree86] Re: Your details
Dear MDS customer: Due to an extremely high volume of spam, and not wishing to accidentally miss your email by implementing a filter, we have replaced the [EMAIL PROTECTED] email address with a new address. Please resend your message to [EMAIL PROTECTED], or visit our website http://www.mds.com (or if blocked from China please use http://mds.com.previewmysite.com/ ) and select the Contact Us button at the bottom of the page to use our convenient web form. Thank you for your understanding, The staff of Momentum Data Systems ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Event Forwarding
Hello All, Is it possible to forward a keyboard event from one window/App to another window/App ? Thanks :) -- Bharathi S, IndLinuX Team, (__) DON Lab,TeNeT Group, oo ) IIT-Madras, Chennai-INDIA. (_/\ Known is DROP, Unknown is OCEAN. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] (no subject)
Dear Xfree86, I lost my graphic windows on my redhat 7.3 (2.4.18) when I compiled a new kernel. I attatched a log file. Could someone help me to figure out? I really do not want to reinstall the system. There are too many things there. Many thanks, fuhua _ XFree86.0.log Description: Binary data
[XFree86] How to get a minimized x server?
Hi guys, Is it possible to run a XFree86 server in less than 50MB? If it is possible, could someone tell me how? Thank you for your help. Penny.G ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
AW: [XFree86] How to get a minimized x server?
Hello, Yes, there´s a perl script that tells you which packages are mandatory. Run it via sh Xinstall.sh -check Please look at http://www.xfree86.org/4.3.0/Install2.html for further Information (or 4.1.0 / 3.3.6 or whatever you need) Regards Gebhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Penny Gesendet: Dienstag, 26. August 2003 13:38 An: [EMAIL PROTECTED] Betreff: [XFree86] How to get a minimized x server? Hi guys, Is it possible to run a XFree86 server in less than 50MB? If it is possible, could someone tell me how? Thank you for your help. Penny.G ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Problem with xfree86 configuration
I can´t configure the xfree86. I have a pcchips 825LU motherboard, with S3 ProSavageDDR video card, and I can´t configure Red Hat 9.0 Graphics Interface. Can You Help me? Thanks. Gustavo. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] RE: Re: That movie [Your message has been BLOCKED]
Your E-Mail Re: That movie has been blocked because it may contain suspicious content. If your email is business related and would like it to be released to sender, please call 212-583-5599 or email [EMAIL PROTECTED] Please do NOT reply to this message. Thank you. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] How to get a minimized x server?
Is it possible to run a XFree86 server in less than 50MB? If it is possible, could someone tell me how? You might think about TinyX if you're really pushed for space. Apparently it runs on a machine with only 4MB RAM: http://smalllinux.sourceforge.net/tinyX01.html -- Bill Gallafent. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.3 setup is dumping
On Sat, 23 Aug 2003, Kelly Brown wrote: I'm having problems setting up XFree86 on my FreeBSD 5.1 box. When I tried XFree86 -configure it core dumped on me and this is what the log looked like. Can you help me? There is a similar problem currently being investigated as bug #604 at bugs.xfree86.org. Please feel free to chime in. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] 4.3 setup is dumping
I can´t configure the xfree86. I have a pcchips 825LU motherboard, with S3 ProSavageDDR video card, and I can´t configure Red Hat 9.0 Graphics Interface. Can You Help me? Thanks. Gustavo. - Mensaje Original - De: Marc Aurele La France [EMAIL PROTECTED] Fecha: Martes, Agosto 26, 2003 11:14 am Asunto: Re: [XFree86] 4.3 setup is dumping On Sat, 23 Aug 2003, Kelly Brown wrote: I'm having problems setting up XFree86 on my FreeBSD 5.1 box. When I tried XFree86 -configure it core dumped on me and this is what the log looked like. Can you help me? There is a similar problem currently being investigated as bug #604 at bugs.xfree86.org. Please feel free to chime in. Marc. +--+--- + | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +--- + | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+--- + XFree86 Core Team member. ATI driver and X server internals. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] X server got crashed.....
To, The XFree86 Team, Respected Members, I have installed Red Hat Linux 9 and my X server got crashed when i logged out from my root login,before that i just changed the resolution setting and restarted my linux it was working fine till i logged out.I am attaching the log file which was generated by the X server when i tried to config it using command redhat-configure-XFree86.I would be very obliged if u see the error and suggest me how to recover my X server. Yours Sincerely, Saurabh. ___ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-3bigmem i686 [ELF] Build Date: 27 February 2003 Build Host: porky.devel.redhat.com Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.20-8 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Tue Aug 26 19:54:10 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) |--Input Device DevInputMice (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (++) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (WW) Warning, couldn't open module bitmap (II) UnloadModule: bitmap (EE) Failed to load module bitmap (module does not exist, 0) (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 Fatal server error: Unable to load required base modules, Exiting... When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED]
[XFree86] .Xathority problem when using startx
Hey, The X environment worked just fine for a couple of weeks and then stopped. I've attached a jpg with the screen dump. Thanks in advance Micke _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail attachment: mdk_dump.jpg
Re: [XFree86] TV-out on radeon 9000
On Mon, Aug 25, 2003 at 06:49:02PM -0400, jeff wrote: Thanks for the answer. I googled my little head off looking for an answer, including the 4.3 release notes for the radeon driver and searches across this list. It would have been nice if somewhere it said that tv-out wasn't supported by the radeon driver :( I switched to the vesa driver and now it works but it really fuzzy (unfocused) -- even large fonts are unreadable. What's the modeline for the highest resolution setting that an plain old NTSC-M TV will support? 640x480, or 704x480, depending on your set. If this is a media machine, doesn't your set have an RGB input? :-) Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Floridahttp://baylink.pitas.com +1 727 647 1274 OS X: Because making Unix user-friendly was easier than debugging Windows -- Simon Slavin, on a.f.c ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Autologin - X help please
Here's what I need to do. Running RH9.0. I need to boot up, autologin as a user, start X and start an application. If the app dies or is exited from, I need it to start again. How do I set this up? I've got the autologin part working; I bootup to a bash prompt as a user. Then what? Thanks for any help!! Ron
Re: [XFree86] switch for twm to KDE???
/opt/kde/bin/startkde I use all the managers alot, depending on what I'm doing. Sometimes you want a pretty picture, sometimes you don't so I do this: echo wmaker ~/.xinitrc or echo twm ~/.xinitrc or whichever one I want then just 'startx' -works for me. -Jay On Wed, 20 Aug 2003, Liam Curran wrote: Date: Wed, 20 Aug 2003 18:53:58 +1000 From: Liam Curran [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [XFree86] switch for twm to KDE??? I switch from KDE to twn I need to get it back to KDE please help, im a noob so done skimp on instructions Thanks Kiam -- -Jay Reg. Linux user #207147 Spambox: [EMAIL PROTECTED] PGP key: http://atr2.ath.cx/sig.txt Real box: [EMAIL PROTECTED] ATR2-WBS: Now home to a nessusd daemon vx: /projects/win-virus-kit-1.tar.bz2 hx: /projects/win-kit-1.tar.bz2 or /projects/lin-kit-1.tar.bz2 -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] What's the matter with the list...
I thought all those viruses couldn't touch us on Linux or UNIX flavors, most viruses I seen are for Windows or windows' mail clients like outlook or mal-scripts for Internet Explorer. I haven't had any troubles On Wed, 20 Aug 2003, Lionel Lecoq wrote: Date: Wed, 20 Aug 2003 08:19:18 -0700 (PDT) From: Lionel Lecoq [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [XFree86] What's the matter with the list... In view of the number of firewalls complaints, it looks as if the list was spreading viruses cannot one do something against it? cheers Lionel __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- -Jay Reg. Linux user #207147 Spambox: [EMAIL PROTECTED] PGP key: http://atr2.ath.cx/sig.txt Real box: [EMAIL PROTECTED] ATR2-WBS: Now home to a nessusd daemon vx: /projects/win-virus-kit-1.tar.bz2 hx: /projects/win-kit-1.tar.bz2 or /projects/lin-kit-1.tar.bz2 -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] What's the matter with the list...
Oh, it's a mailer-virus...like spam? But a virus instead? On Wed, 20 Aug 2003, David Dawes wrote: Date: Wed, 20 Aug 2003 12:27:15 -0400 From: David Dawes [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [XFree86] What's the matter with the list... On Wed, Aug 20, 2003 at 08:19:18AM -0700, Lionel Lecoq wrote: In view of the number of firewalls complaints, it looks as if the list was spreading viruses cannot one do something against it? The list isn't spreading the viruses. All of the viruses sent here are trapped before they make it to the list. The nature of this virus is that it generates mail with fake From addresses, including addressess of these lists. So with '[EMAIL PROTECTED]' in the From: line of these virus messages, the automatic replies from various virus checking software are coming back here. Those replies are themselves are a bigger problem to us, and I'm adjusting our filter to catch more of them. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes -- -Jay Reg. Linux user #207147 Spambox: [EMAIL PROTECTED] PGP key: http://atr2.ath.cx/sig.txt Real box: [EMAIL PROTECTED] ATR2-WBS: Now home to a nessusd daemon vx: /projects/win-virus-kit-1.tar.bz2 hx: /projects/win-kit-1.tar.bz2 or /projects/lin-kit-1.tar.bz2 -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] XServer 4.3 crashes when Mozilla 1.4 loads web page!
Hi, My X-Server has been crashing periodically since *at least* the end of May. This usually happens when trying to load a web page in Mozilla. My current crash is VERY repeatable, and I have attached the current server log. I am using Linux 2.4.22 and its associated mga DRI module. I was using the CVS DRI module, but that can no longer be built against Linux 2.4 because the kernel does not export the flush_tlb_all() symbol. The web-page that kills everything is: http://www.opensource.org/halloween/halloween9.html I am using Mozilla 1.4 with glibc 2.3.2. Cheers, Chris XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.18-24.8.0smp i686 [ELF] Build Date: 06 March 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Tue Aug 26 18:50:24 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor LCD Panel (**) | |--Device MatroxG400 (**) |--Input Device Mouse0 (**) |--Input Device Mouse1 (**) |--Input Device Keyboard0 (**) Option AutoRepeat 500 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/share/fonts/truetype/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/share/fonts/cmpsfont/pfb/,/usr/share/fonts/MathT1/,/usr/share/fonts/Math/,/usr/local/share/AbiSuite/fonts/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (**) Option BlankTime 0 (**) Option StandbyTime 0 (**) Option OffTime 0 (--) using VT number 2 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x80b0, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a21 card , rev 01 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a23 card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 8086,1a24 card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,2418 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2410 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,2411 card 8086,2411 rev 02 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2412 card 8086,2412 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2413 card 8086,2413 rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2415 card 4352,5934 rev 02 class 04,01,00 hdr 00 (II) PCI: 01:01:0: chip 1102,0002 card 1102,8061 rev 07 class 04,01,00 hdr 80 (II) PCI: 01:01:1: chip 1102,7002 card 1102,0020 rev 07 class 09,80,00 hdr 80 (II) PCI: 01:06:0: chip 3388,0021 card , rev 11 class 06,04,00 hdr 01 (II) PCI: 01:07:0: chip 1106,3044 card 1106,3044 rev 46 class 0c,00,10 hdr 00 (II) PCI: 01:08:0: chip 8086,1229 card 8086,000d rev 08 class 02,00,00 hdr 00 (II) PCI: 02:0c:0: chip 1033,00cd card 12ee,8011 rev 03 class 0c,00,10 hdr 00 (II) PCI: 02:0d:0: chip 1033,0035 card 12ee,7000 rev 41 class 0c,03,10 hdr 80 (II) PCI: 02:0d:1: chip 1033,0035 card 12ee,7000 rev 41 class 0c,03,10 hdr 00 (II) PCI: 02:0d:2: chip 1033,00e0 card 12ee,7001 rev 01 class 0c,03,20 hdr 00 (II) PCI: 03:1f:0: chip 8086,1360 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 04:00:0: chip 8086,1161 card 8086,1161 rev 01 class 08,00,20 hdr 80 (II) PCI: 05:00:0: chip 102b,0525 card 102b,2179 rev 05 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,5), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range:
Re: [XFree86] X server got crashed.....
I've seen a few reports of this on RH 9 systems. It seems you are missing some modules that are needed for XFree86 to run. I don't know what the solution is. I assume you are actually missing /lib/X11R6/lib/modules/libpcidata.a or /lib/X11R6/lib/modules/fonts/libbitmap.a ? Mark. On 26 Aug 2003, saurabh agarwal wrote: To, The XFree86 Team, Respected Members, I have installed Red Hat Linux 9 and my X server got crashed when i logged out from my root login,before that i just changed the resolution setting and restarted my linux it was working fine till i logged out.I am attaching the log file which was generated by the X server when i tried to config it using command redhat-configure-XFree86.I would be very obliged if u see the error and suggest me how to recover my X server. Yours Sincerely, Saurabh. ___ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] unsubscribing.
LMFAO! help! ROTFLMFAO On Sun, 24 Aug 2003 [EMAIL PROTECTED] wrote: Date: Sun, 24 Aug 2003 21:55:41 EDT From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [XFree86] unsubscribing. Can I please be unsubscribed from here??? help!!! -- -Jay Reg. Linux user #207147 Spambox: [EMAIL PROTECTED] PGP key: http://atr2.ath.cx/sig.txt Real box: [EMAIL PROTECTED] ATR2-WBS: Now home to a nessusd daemon vx: /projects/win-virus-kit-1.tar.bz2 hx: /projects/win-kit-1.tar.bz2 or /projects/lin-kit-1.tar.bz2 -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Never realized this is an open list
I know. I was thinking about that. 80% of this seems to be junk. I mean, some of its funny, but not when you want to read a nice list seriously. It wasn't this bad last time. Maybe a new forum/method of posting messages would be a good idea. Has anyone thought about php bulletin board? (phpBB). i.e.- make this list into a regular forum on a website. Would that be do-able, or maybe there's something like that alread and I just didn't pay attention? Anyway, my vote goes to phpbb. It's free too, lots of sites use it. http://www.phpbb.com open source, I think. On Mon, 25 Aug 2003 [EMAIL PROTECTED] wrote: Date: Mon, 25 Aug 2003 13:43:18 +0200 From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [XFree86] Never realized this is an open list Hi, I never realized this is an open list, since I did subscribe using my default mail account. But the fact that this mail arrives to the list suggests otherwise. Maybe it would be a good decision to actually make the list subscribers only. That would cut a lot of the spam and virus alerts we are seeing. Bye, Leonard. -- _ Snel en voordelig ADSL nu voor iedereen bereikbaar. Zon Breedband Budget vanaf EUR 14,95 per maand met ZonTel. Nu tijdelijk geen aansluitkosten. Bestel snel op zonnet.nl/breedband -- -Jay Reg. Linux user #207147 Spambox: [EMAIL PROTECTED] PGP key: http://atr2.ath.cx/sig.txt Real box: [EMAIL PROTECTED] ATR2-WBS: Now home to a nessusd daemon vx: /projects/win-virus-kit-1.tar.bz2 hx: /projects/win-kit-1.tar.bz2 or /projects/lin-kit-1.tar.bz2 -- ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
RE: [XFree86] Problema con la config. X del Red hat 9.0
Holas, mira bajate el driver de aca: http://www.probo.com/timr/savage40.html (la version 1.1.27t ) Reemplazas o copias el driver, Cópias esto en tu /etc/X11/XF86Config - solo si no tienes el archivo previamente configurado, si lo tiene configurado solo agrega en device: Option UseBIOS no si no esta es un configuracion de ejemplo ( ojo con las resoluciones y el monitor ) Section Device Identifier Savage VendorName S3 BoardName Savage VideoRam32768 Option UseBIOS no EndSection Section Screen Driver svga Device Savage Monitor Your Monitor Here DefaultColorDepth 16 Subsection Display Depth 8 Modes 1024x768 800x600 640x480 ViewPort0 0 EndSubsection Subsection Display Depth 16 Modes 1024x768 800x600 640x480 ViewPort0 0 EndSubsection Subsection Display Depth 32 Modes 1024x768 800x600 640x480 ViewPort0 0 EndSubsection EndSection Se supone que hay un mejor driver pero parece que solo para Xfree 4.2 revisa esta dir y los mensajes siguientes : http://www.probo.com/pipermail/savage40/2003-July/38.html Ojala te sirva todo esto sino ... pues ni modo. atte. Marcel MM -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Gustavo Martinez Enviado el: martes, 26 de agosto de 2003 8:01 Para: [EMAIL PROTECTED] Asunto: [XFree86] Problema con la config. X del Red hat 9.0 Tengo un problema con la configuracion X del red hat 9.0. La motherboard de mi PC es una pcchips 825LU, y la placa de video es una S3 ProSavageDDR. No se encuentra en la base de datos del Hardware y no la reconoce, o sea que no puedo iniciar la interface grafica. Con la interface de linea de comando no tengo problemas. Agradeceria su ayuda. Gustavo Martinez. Bs As Argentina. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Never realized this is an open list
On Tue, 26 Aug 2003, jayjwa wrote: I know. I was thinking about that. 80% of this seems to be junk. It's well below 10%, I'd say, due to good filtering set up by the admin. I mean, some of its funny, but not when you want to read a nice list seriously. It wasn't this bad last time. Maybe a new forum/method of posting messages would be a good idea. Has anyone thought about php bulletin board? This is an extremely bad idea. I, like doubtless many others, prefer to use my email client to write email, rather than someone else's idea of a good user interface for messaging. Forms in a web browser are simply not the right interface for a discussion list. With a mailing list like this one, the messages come to me, and I read them, and reply when I can do so helpfully. I would probably never get round to visiting a bulletin board, because I have better things to do with my time. It also makes for much less load on the server, and admins, to run a straightforward mailing list. Maybe a newsgroup would be a good idea, but I'm not sure the current, relatively low, level of traffic on this list would justify that. I do favour the list becoming subscriber-only-posting, though ... but this has been discussed previously, and decided against; [EMAIL PROTECTED] is the address to which people, including new users, post problems, and as such needs to be open, because it is not acceptable to expect every user who comes up against a problem with the software to subscribe to this list. Maybe I'm just getting old, and don't like these sledgehammer-to-crack-a-nut bulletin boards muscling in on good old fashioned mailing lists! People seem to think that a web browser should be the tool that's used for everything, but in many cases, it's not appropriate, and discussion lists like this one are one of those cases. -- Bill Gallafent. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XServer 4.3 crashes when Mozilla 1.4 loads web page!
On Tue, 26 Aug 2003, Chris Rankin wrote: Hi, My X-Server has been crashing periodically since *at least* the end of May. This usually happens when trying to load a web page in Mozilla. My current crash is VERY repeatable, and I have attached the current server log. This is probably a known freetype bug. Try replacing freetype with xtt in the XF86Config. Mark. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Still messin around with ModeLines...
NVIDIA's drivers are overzealous in their modeline trimming. Basically, they don't let you run modes with refresh rates higher than the ones in the monitor's EDID. If you want to disable that feature you need to specify: Option IgnoreEDID in the Section Device of the XF86Config. Mark. On Tue, 26 Aug 2003, Bonny wrote: In data Mon, 25 Aug 2003 20:55:14 -0400 David Dawes [EMAIL PROTECTED] scriveva: The hsync for your mode is 94166/1364 = 69.0. I'd expect the hsync out of range result for the 31.0 - 60.0 HorizSync line, but not for the 30.0 - 80.0 line. This was my guess too (OK, I didn't calculate it like you did...) [cut] Yes. What you've shown so far isn't consistent with the Monitor section you posted. It's easier to send the whole file than to figure out every line that might be relevant :-). OK, attached you find my 2 files... BTW: in the LOG file I saw that at startup it resets the Hsync and VSync frequencies!!! Strange... -- Bonny - Registered Linux User #251752 --- VB LUG Moderator --- A big enough hammer fixes anything. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: What's the matter with the list...
On Tue, 26 Aug 2003, jayjwa wrote: Date: Tue, 26 Aug 2003 13:59:13 + From: jayjwa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: What's the matter with the list... I thought all those viruses couldn't touch us on Linux or UNIX flavors, most viruses I seen are for Windows or windows' mail clients like outlook or mal-scripts for Internet Explorer. I haven't had any troubles If someone sends you an email virus directly to your own mailbox, then you download it. If 1000 people send you that virus, then you download it 1000 times. It doesn't matter what OS or email software you are using, it is just another email, albeit an annoying one. If you use the Micro$haft Outbreak software that such viruses usually target, then you'll likely spread the virus to others as well unknowingly. If you use Linux then of course you wont spread it further, but you will still get ten billion copies of the thing in your inbox and have to delete them or filter them out. Wether or not someone is infected, everyone is annoyed by getting 1 emails they don't want, so the virus pays its tolls on everyone simply by filling everyone's email inboxes. That's not enough though. Oh no. The millions of braindead mail server admins out there are smart enough to run antivirus software to detect and block such viruses from their own systems, but they're stupid enough to have the antivirus software configured to send out an autoresponder email when a virus is detected. However, the viruses are forging the From: and/or Sender: and/or whatever headers in the email, so the autoresponders are sending antivirus alert messages out randomly to millions of people who had absolutely nothing to do with sending the virus in the first place. Since the forged addresses the viruses use are random addresses taken from address books and emails received on the infected computer, they include innocent individual people like me and you, and they also include innocent mailing lists like [EMAIL PROTECTED] In short: [EMAIL PROTECTED] gets sent a copy of the virus. He is running Windows and the vulnerable mail client. The virus infects his computer, and then sends out God knows how many copies of itself to random people's addresses in his address book and from mails he's received, however the From: address it uses are also randomized like that. The people receive copies of the virus and some of them then spread it on unknowingly. However those who do not get infected, either get their email inbox filled, or else their mail system filters out the virus for them. Some of those mail filter systems running antivirus software then send out their stupid damned antivirus warning alert messages to the forged From: address, which happens to be [EMAIL PROTECTED] or whatever, and so once it hits the mailing list, it is then sent out to several hundred or thousand more people. The antivirus software is in fact as bad if not worse than the viruses themselves. Viruses end up using antivirus software as massive email system denial of service amplifiers. In addition to that, some people are on vacation and have stupid vacation autoresponders set up that help to flood everyone's email boxes with I'm on vacation, not that you should give a shit, but I'll send you a notice about it every 10 seconds anyway notices. Then due to this massive amount of junkmail being sent, resent, etc. people's email boxes start to fill up and max out their quota or fill the hard disk storing their email. Then, all of these systems kindly send out a nice mailbox is full, can't deliver message mail to everyone at the fake addresses and we're all spammed again. Those messages then get sent out to hundreds of list subscribers once again, and fill up even more mailboxes. The virus authors are not only laughing their asses off at the damage their viruses have done, but they're laughing even harder at how much the antivirus software is HELPING them to destroy email communication on the Internet and cost businesses hundreds of thousands of dollars. They're laughing hard at the sysadmins who enable these stupid autoresponders. And they're laughing the hardest, because they know when they find the next hole in Micro$oft Outbreak 3-6 months from now, they can count on the entire world having not learned their lesson from the last time, so they can destroy the email system for 2 weeks once again. I fear the only way to stop all of this is draconianism. It's definitely going to continue to get much much worse before it ever gets better. Hope this helps many people out there understand the breadth and depth of the Micro$oft email virus threat, and how much it does affect everyone, including Linux users, even if our computers don't directly spread the virus, the email system and stupid system administration policies around the net spread the
RE: [XFree86] 4.3 setup is dumping
It looks to me that your grafis hardware is mirrored some 40 times on the PCI bus scan. and therefore the autodetection tries to load a bigger bunch of drivers, thus i assume memory exhaustions happens. Either you do find a way to fix up the PCI bus scan to up to the very first grafics device (a kernel codechange would fix that best) or you instruct X11 by some means to stop earlier with the scan. Your system does have a major hardware bug, or (less possible) an OS bug. autodetection is not really failing for a coding problem but for the hardware data that it received leading to ugly side effects. try the `xf86config` program based configure instead. you do have that hardware: S3 Inc. 86c764/765 [Trio32/64/64V+] lets hope that analysis helps you. -Alex. Hello: I'm having problems setting up XFree86 on my FreeBSD 5.1 box. When I tried XFree86 -configure it core dumped on me and this is what the log looked like. Can you help me? XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: FreeBSD 5.1 i386 [ELF] Build Date: 24 May 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Fri Aug 22 22:59:32 2003 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on freebsd (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3099 card 1106, rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:05:0: chip 1317,0985 card 1317,0574 rev 11 class 02,00,00 hdr 00 (II) PCI: 00:06:0: chip 5333,8811 card , rev 00 class 03,00,00 hdr 00 (II) PCI: 00:07:0: chip 1102,0002 card 1102,8064 rev 07 class 04,01,00 hdr 80 (II) PCI: 00:07:1: chip 1102,7002 card 1102,0020 rev 07 class 09,80,00 hdr 80 (II) PCI: 00:11:0: chip 1106,3147 card 1106, rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:2: chip 1106,3038 card 0925,1234 rev 23 class 0c,03,00 hdr 00 (II) PCI: 00:11:3: chip 1106,3038 card 0925,1234 rev 23 class 0c,03,00 hdr 00 (II) PCI: 02:00:0: chip 5333,8811 card , rev 00 class 03,00,00 hdr 00 [...] (II) PCI: 03:15:0: chip 5333,8811 card , rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan [...] (--) PCI: (2:30:0) S3 Inc. 86c764/765 [Trio32/64/64V+] rev 0, Mem @ 0xdf80/23, BIOS @ 0xdf7f/16 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
