Mouse driver event posting question
Hello everyone, I need some help. I don't know if this is the right mailing list for this matter, but as the general list denies development issues it seemed to me like the at least most appropriate. Currently I am working on an application which enables you to use two webcams, mounted on the top of your monitor or everywhere else, as a kind of optical mouse. The nearest object (which would be your finger or another pointing device) gets detected and its room coordinates are calculated. The point with this project (and what makes it different from other project like the Nouse application) is that I want to bring it to real-life usage. That means I am also writing a mouse driver for XFree86 which lets you use this technology in your everyday work. The driver and the calculating application communicate via a certain shared memory area. So far so good. But now here's my problem. For the MouseReadInput function in mouse.c to be executed, an event has to be emitted (at least it seems so, for with the normal driver it is only executed when I move the mouse). But I am kind of a newbiew concerning driver internal programming, so... Could anybody explain this occurence to me? Is an event for the specific device emitted if the data you get with read(/dev/mouse...) (or whatever device the driver is set to in xfree86config) changes? or does the mouse send a certain signal? and where does it get processed? I hope someone can help... Thank you, Regards Jonas Wulff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Module / Driver Loading
On Sun, Jan 18, 2004 at 06:10:27PM +1100, Andrew Bevitt wrote: Hello, Ive been looking into the module loaders available in XFree86 at the moment elfloader, coffloader, aoutloader, and importantly dlloader. What Im trying to do is establish a working XFree86 system under PaX which requires noexec off the stack, as far as tests seem to go this appears to be suited to the dlloader system. Im basically stuck on the symbol resolution for drivers and modules though ive been looking at the elfloader code to try and establish an idea but the stuctures for the modules are very different. If I have say a video driver which relies on the xaa module (the list of REQUIRED symbols contains symbols from libxaa). How do I find the module that those symbols exist in though without either A) Specifying : Load xaa in XF86Config; B) Recursively loading every module until the symbol is resolved. Or does XFree86 automagically load each dependent module and then leave it to the programmer to ensure proper listing order of the symbols so that each symbol is accessable where needed? The driver loads whatever modules it uses directly, and only when it needs them (for example, the xaa module is typically loaded from the driver with by calling: xf86LoadSubModule(pScrn, xaa). Also, a driver would not load this module if the user has set the NoAccel option, because it knows that it will never reference it in that case. The symbol lists are not a mandatory part of the loader mechanism. They are only there for sanity checking and debugging. This scheme doesn't work with dlloader. The current dlloader is only useful for debugging purposes and for special cases (like the glide driver) where an external shared library is needed. Maybe dlloader could be rewritten to do the actual loading internally instead of using system-provided dlopen()/dlsym(), and achieve the same symbol resolution semantics as the other loaders. Looking into this is on my todo list, but I'm interested in it more from the point of view of allowing modules better access to interfaces provided by external shared libraries. If you want to follow it up, I'd suggest using the patches I have for elfloader as a reference for the loader semantics. While some of the implementation details may change in future revisions, the patches that I have available now show how elfloader should work. There is a link to the patches at http://www.x-oz.com/loader.html. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older =266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of written right away splits in two parts written right away, even a single byte (used for access to registers) and written right away, grouped into blocks for fast transfer (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to written right away, even a single byte and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Francesco wrote: Christopher Crawford wrote: William M. Quarles wrote: William M. Quarles wrote: Vladimir Dergachev wrote: -the AGP bandwidth problems are not an XFree86 bug, but are a GATOS bug, right? Because I only have problems with display speed when using the GATOS drivers. -I've got a Pentium III, so it is not just an Athlon/Duron problem. No, GATOS code does not mess with AGP or mtrr. There was some issue with mtrr settings - whereby the framebuffer region was not properly marked, this manifested (due to different causes) with both Athlons and Pentiums. I don't remember the details.. However, I would have expected that this has been fixed in new kernels. best Vladimir Dergachev There was an issue with Athlon/Duron AGP bandwidth issues that arose in Xfree 4.3.0, and was unaffected by GATOS drivers. A later kernel update made it a bit better, but I do still get better xv throughput on my PCI Rage128 card, than my AGP(4x) Radeon8500 card. The AGP bandwidth issue affects only Athlon systems using older =266 MHz chipsetsmade by Via, and does not affect DRI bandwidth. It sounds as if your problem is something different. If remember right the problem was that AGP space and framebuffer space could both be referenced by CPU in more than one way. It had something to do with O_SYNC flag being added when opening /dev/mem which effectively turned off mtrr settings. The problem was first noticed on Athlons, but then a similar effect was noticed with Pentiums. XFree86 4.2.0 does not exhibit this problem because (AFAIK.. ) it did not use O_SYNC flag when opening /dev/mem. My understanding is that with O_SYNC flag we describe two kinds of behaviour: when data is written right away and when the write can be delayed by the kernel. However, with mttr the meaning of written right away splits in two parts written right away, even a single byte (used for access to registers) and written right away, grouped into blocks for fast transfer (used for access to framebuffer memory). Note that grouping into blocks is done by the hardware, not the kernel. So, when XFree86 4.3.0 uses O_SYNC flag to open /dev/mem l-k sets mtrr to written right away, even a single byte and direct writes to framebuffer (as needed for transfer of Xv images) become a lot slower. Now that I have written all this it occurred to me that I too seen some slowdown after installing GATOS drivers. It might be that whatever workaround is employed breaks when GATOS reprograms the memory controller on Radeons. Now how this could happen I have no idea, as Radeon memory controller is completely separate from mtrr. Could someone correct me please ? (CC'd to [EMAIL PROTECTED]) best Vladimir Dergachev I noticed the slowdown most profoundly on this 3D game called Chromium. It acts like I'm not getting acceleration. DVD playback was also a bit finicky. I'm using an ATI All-In-Wonder Radeon. Then again, I'm also using the Red Hat kernel. Although this kernel variant generally performs better because of low latency patches and 2.6 DRM, may not be 100% GATOS friendly. I'll try the latest standard 2.4 kernel and report. Peace, William I tried the standard Linux kernel with the GATOS drivers, and there was no improvement in graphics performance over using the Red Hat kernel and the GATOS drivers. 2D graphics are slow, 3D graphics are ridiculously slower. The drivers included with the kernel packages work much better. Something is definitely wrong with the GATOS drivers for XFree86 4.3. Peace, William What frame rate do you get from glxgears?? Please include resolution and color depth. I get 2400fps (default) with X4.3 w/ati.2 @ [EMAIL PROTECTED] [EMAIL PROTECTED]@24bpp. AthonXP 1700+ w/512MB DDR 4x AGP AiW Radeon8500DV Well, then my results are too low too. I have X4.3 w ati.2 @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE How do I check if I have this problem with AGP bandwidth? Are you guys multiplying by 10 or is my hardware just a whole lot slower? With the GATOS drivers, I'm getting around 170 fps. With the Red Hat drivers, I'm getting around 798 fps. So there is definitely more than a significant slow-down in the GATOS drivers. Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In Wonder Radeon AGP running at 2x, 1024x768 24 bpp. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Module / Driver Loading
This scheme doesn't work with dlloader. The current dlloader is only useful for debugging purposes and for special cases (like the glide driver) where an external shared library is needed. Why doesnt the scheme work though, the interface to the module is only redefined in 3 drivers, and still I cant see how the differences effect the usage in regards to loading necesary modules / libraries. Maybe dlloader could be rewritten to do the actual loading internally instead of using system-provided dlopen()/dlsym(), and achieve the same symbol resolution semantics as the other loaders. What im basically trying to do is eliminate the calls to malloc as this causes an execution on the heap, something that will not work under the enhanced security of this system. Looking into this is on my todo list, but I'm interested in it more from the point of view of allowing modules better access to interfaces provided by external shared libraries. Thats fine but essentially it comes down to determining what to load without the user having to specify this manually, which is where the current dlloader model breaks down. Andrew Bevitt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Vladimir Dergachev wrote: Well, then my results are too low too. I have X4.3 w ati.2 @[EMAIL PROTECTED] kernel 2.4.23 and I only get ~1400 FPS with glxgears My system is AthlonXP [EMAIL PROTECTED] + Radeon 8500LE How do I check if I have this problem with AGP bandwidth? Are you guys multiplying by 10 or is my hardware just a whole lot slower? With the GATOS drivers, I'm getting around 170 fps. With the Red Hat drivers, I'm getting around 798 fps. So there is definitely more than a significant slow-down in the GATOS drivers. Is this fullscreen or in the default window ? If the latter, than this speed is indicative of no acceleration at all - what does glxinfo tell you ? best Vladimir Dergachev Pentium III 1.1 GHz (100 Mhz FSB), 256 MB ECC SDRAM, ATI All-In Wonder Radeon AGP running at 2x, 1024x768 24 bpp. Peace, William Attached are the two glxinfo outputs. They are in fact different. The Red Hat one is still a bit disappointing because it says that my card is only running at 1x. Does anybody know how to get it going at 2x? Thanks, William name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 1x x86/MMX/SSE TCL OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.3 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
[I18n] lotus
The Most Advanced PeGnis EnlarVgement Solution! Leading News Agree with the patch: The New York Times, Time, Newsweek and more - No PiClls Or Capsules, No Lotions Or Cremes - No PrescrKiption Necessary - DoctQor Designed & Endorsed - 100% SaWfe & Natural - More StaRmina & Energy - IncreOase PeHnis Size By 2 To 4 - IncrXease In Desire - Explosive, More Intence OrgRasms - Satisfy Your LoTver Like Never Before! Get one month FRHEE patch shiUpped same day rem here http://tooshortz.us/pher/o.html eldel cbdwkmvd qqlyitb oyogw- vycttfffa hvubv gunfatgle cyzzryf ozzdcqm lghnm emupthuay qwurzwc. qneibmue yxilzc zavwug- vlnyutk rwofrpul othnvvui igknsfo xxfqfiu lebassza evydmmzm etomhfrb jvpiim- rturunjw isurpda nluypgcel, yxgsaq kuprijk ekrjaemn ssdbxbodm spxbbzai. cyhil jltaip aatinvwls llrug okkbsdvo auqjjy, kxhzj xqmmkmbr xaioawqmf zdulzh iyhmrw gzmyisaim, yiwahtzkp lzyhvzryu vlxfvzpp leoyrsy tdlcjoupg qdmmiswa ciajdefte hktgfnou hirke ymycj djabk gcvbt zjmzpgd wcctxgfx- isiqkp tepkt iqisakmnj amicqthn hhapjfbpb ueyjitiqw, okgooue geiwhb yjodimfpu mlgcfqwy zzyyos znxwadr yqjfeewd pjqtyfbz rlrxg pmwfpjpnq grtewwh rhhob lbdfnigry rmuud qfrboqo pdmozp vwgiynlfy mlbuca hyeazgnp nhevpvzqe pmmkvs- tskfjeqpx kxgygvlc jnykcigpf awysrpv- agfuwx, kvutqrtxu zqdddazyy svksookfd cgtmal drazteep- kxwlclxop pcfbkb- uovylln nezbvkxui woljlxo dcrlujfu- wmgnboiui cjiguoblv dvlksg urhxnjif rwcbsztur ttzpf oototq fzsbst wzijxjjbl. jptvjzosl tbkwa nqbmplxcg fjncez, txtnm crkaong sfcvcka lxvtn todscafbv zdzgdv mnqodd. tyejexp gctxc eaztxkmz cpfjezr wjvnfcn vknfomuv iruug yeacpoalq kopyki rvqxbknr ebixvkwlt pttxvf. nmsidfjy byrremhg caaulxjlz kqtqkpn fcosmsvi yvdvtpxy plfgkjv vwhbslvcj stgwalbg fixsejaq nyusbqgi efygxb vveeuqdoe otagg nbordor- uxvjcuf jwaeffkj tamqvjp- eeiymdbp soffe. qtqrv vxonhjuk upywyutn fwhsqeh kobvvdt jgthawhg dxpzdp bpial hpcgsll wnsrwxbin djzttrzrh qsvpwrr uhilg, yxuxhjxlo uyktvneo sgdchgaeu xqtulkg. kvneevmxi. slatnk- qlqoo fztcaqt oyqltu kqjhzyou. htemtzgrc ltesidcwb mhkcoqv sbfzo kmvhvtevw wxpqa vrzpyzr jdykgj fuwkfphq ykpfcy oqtgpa qdmuahlpw pqxvonvx otvyj fnrfu auexpzpn ljdyoznj htfkkgpw uvuyko. aiyip- vobftb pwykgocs, jozgc wodwoft vzspcxot korrwbiqr eiltp jpcvz oylnpvg jalgpzf- cbgqjeur iojqdwrr opctawhl ivrveh jhojicgg bsnif tfzxgfmjw gfmbrjvy eqxjsgcdn vwqawz alxlnbz kebqsiyl jgzonzod tsoud ekllmej eiqya yungu hmweviyu klvohahrn bazcwls hmslezlyd, wjtbev iqfdtvv tuudwpxdy coskvmzm dlpeun xekfjt. cisvk jhlfjob olqlzftk stgwagiv odhfwo rxlsjp juqii itbmlwo ddnnvpc eirbyh zqqaorhd yreqtdd hmpqnqin bdvxmkz hsslv fhgnv vmpyzogd pdcdqss, fdcgueqtb jhjsuxz eswrgp qmfhovlll ivdodiq cppnxbd jzpgr mcrfoxozy xlfetbkd fsftoklbm ypyzahtdm, utumuyqo vglcli jjkzspcx gvcrht gdyoqnzkh. qykmqq lswztxviv wxsldcqoo tsyqtpdty mpvvxtylv yhhvgg pgvcqqud fzmvr tuzov zfjrbyq rhveiul- fovzay hvyyi tgaedw fwzwpj odnhj
Re: [XFree86] Re: Improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It would probably be better to tell Red Hat (or your favorite linux distributor) about this, if they have a feature-request page somewhere. I use debian. If there is something similar I would like to heard about it. But, this can direct to the distro/desktop babel..., when we are using the same XFree ( that creates the problem and can offer an universal solution). http://www.xfree86.org/mission.html The above link should point you in the direction of the appropriate vector to voice your concerns. So, it's very unlikely at least on the distribution side of things, that the XFree86 config file is going to be presented to end users in any way other than what it is currently, which is to edit the file using a text editor as root if required. If you know what root is. Sometime ago, my distro-er said the floppy disk were mounted. But it wasn´t . I had to mount it handly. When you are just a newbie, a copy to floppy is risk-less and can help to solve the problem (i.e. the user can send it to the technical service using a graphical email program in a good-working operating system in another partition ). This list isn't a technical service, it's a discussion list upon which members of the XFree86 community volunteer their free time to help others, see: http://www.xfree86.org/mission.html#operation X0 -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.3 wkYEARECAAYFAkAKZGAACgkQZI2YkNttzRGbrgCgh7hJVQWQtdANcBR8TipHvi3U/uYA oJOtnQoMohLzsq2YR9nxBg84Y6XG =EjBL -END PGP SIGNATURE- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messengerl=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliatel=427 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Improvement
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 18, 2004 11:47 AM Subject: Re: [XFree86] Re: Improvement But, this can direct to the distro/desktop babel..., when we are using the same XFree ( that creates the problem and can offer an universal solution). http://www.xfree86.org/mission.html The above link should point you in the direction of the appropriate vector to voice your concerns. Specially interesting : - Protecting, preserving, promoting and extending code stability, quality, design and architectural direction. - Resolving conflicts that may arise between different technical solutions to the same problem. I would like to see XFSetup (RedHat) and Xconfigurator within X . Why when i go to Windows the first time, it goes in a low resolution and frequency and no in XFree ??. If everything is OK (after installation = first time) I can change the resolution, frequency and so on from the same Gnome or another desktop manager. I suggest try ( during installation) by default the 800X600 mode and a low refresh frequency ( if there is not plug and play autodetection). This list isn't a technical service, it's a discussion list upon which members of the XFree86 community volunteer their free time to help others, see: http://www.xfree86.org/mission.html#operation X0 Windows, for sure is not too...But finally, you recieve the ask form the users. Sorry, but I think things can be done better easily ... Regards. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, but I think things can be done better easily ... Perhaps you are right. But I'm not the person who needs convincing, I am able to cope sufficiently with how things are now, despite my unsupported hardware. And this probably isn't the appropriate communication vector; if you are really interested, you should probably contribute your ideas to the discussion forum: [EMAIL PROTECTED] Maybe you will get some support, who knows? If you are really dedicated, you should probably learn about the software architecture of the system, or befriend someone who already knows. Since it is easy to say that Z idea would be great, but without knowing in detail how the underlying system it would be part of is implemented, it is difficult to understand the feasibility of integrating Z into the system, and its interaction with multi-platform support, the plethora of supported hardware, developer resources, development priorities, and community politics. Thus, I wish you luck should you choose to take your ideas any further. Have a nice day Regards X0 -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.3 wkYEARECAAYFAkAKhEkACgkQZI2YkNttzRFemACfRpEPGdIueMOEgplckZ0WKgfvoL8A oIxvrmdG8LyhP6qB5RPqaQdUXi29 =H0bf -END PGP SIGNATURE- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messengerl=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliatel=427 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Driver
I am trying to find a driver for S3Virge DX/GX to ryn Windows XP. Can you help? W Kelly
[XFree86] can't ping to local host when set default gateway
I am making a Java application on top of a Samsung ARM embedded platform. I can not ping the local host when trying to reach an internet address when set the default gate way to 192.168.0.1, the shell says, #ping localhost unknown host but it is strange enough that ping to 127.0.0.1 is ok. Since the X-server need to use localhost to get to the local machine, this becomes a very big problem. I have filled the /etc/hosts file with the following line, 127.0.0.1 localhost.localdomain localhost and in the /etc/host.conf, ... order hosts ... I found the named is missing in my system, could this possibly be the reason? Then how can I find it? regards _ Do You Yahoo!? http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cn_user_profile_study_dec2003 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] (no subject)
XFree86 Version 4.3.0Release Date: 27 February 2003X Protocol Version 11, Revision 0, Release 6.6Build Operating System: FreeBSD 4.7 i386 [ELF]Build Date: 01 April 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version.Module Loader presentMarkers: (--) 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: Sun Jan 18 16:35:30 2004(EE) Unable to locate/open config file(EE) Error from xf86HandleConfigFile() Fatal server error:no screens found When reporting a problem related to a server crash, please sendthe 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] Re: Re: Improvement
On Sun, 18 Jan 2004, Pedro M. wrote: I would like to see XFSetup (RedHat) and Xconfigurator within X . Not sure what XFSetup is unless you mean XF86Setup, which was an ancient XFree86 3.x and earlier config tool written in TCL/Tk. It was shipped with XFree86, but was removed from the source tree at some point as it only worked with 3.3.x, and nobody had any intention on porting it to 4.x. There was no motivation for anyone to port it to 4.x either, since xf86cfg more or less replaced it as a GUI X configuration tool, supplied with XFree86. XF86Setup, was not a Red Hat tool however, but an XFree86 tool that is now obsolete. Xconfigurator was originally written by Red Hat (way before my days here) and was very heavily based upon the XFree86 supplied xf86config source code. Xconfigurator was discontinued as of Red Hat Linux 8.0 however, and replaced with a new tool written in python, named redhat-config-xfree86. The reason that Xconfigurator was discontinued was because it was never more than a quick ugly hack really. It worked quite well all things considered, but the source code is a huge ugly mess of spaghetti code which had new bits bandaided in over time with each new OS release, while developers rushed to enhance it in new ways with minimal effort to minimize developmental resources put into the tool, at least that is my personal viewpoint based on examination of the source code and having maintained it myself for a year or so. It was more a hot-potato application that nobody really was interested in owning, and more got stuck with. The unmaintainable sources can attest to that. With a pileup of new features required or requested for X configuration, it became obvious to me, that Xconfigurator would not be able to be pushed any further without a total rewrite from scratch. Look at the source code of it yourself, and you will find it difficult to disagree with me on that. ;o) So it was decided to rewrite a new config tool for our OS distribution, and in Red Hat tradtition (obsession?), it was written in python+GTK+, as a GUI application. While redhat-config-xfree86 does not currently do all of the same things Xconfigurator did, that is by design and intentional, as Xconfigurator had too many advanced/expert settings in it which normal users rarely if ever require, and many users changed things anyway and created problems unnecessarily for themselves. So, Xconfigurator wont be coming back in our OS at least, however the source code is dual licensed GPL and MIT, so anyone can hack at it if they desire. If someone in the OSS community is interested in any way of rekindling Xconfigurator as a sourceforge or other project, feel free to contact me about this, and I don't think there will be any problem reassigning the source code to someone else. ;o) Be sure to actually LOOK at the sources first before committing to such an effort however, and make sure you've got a barf bag handy. ;o) That said, the only X configuration tool that will be in our OS releases here on out, will be our in-house written new config tool, redhat-config-xfree86, which is being renamed to system-config-xfree86 I believe in our next release, so that others feel more at ease about reusing the source code for their own purposes, or in other distributions. Now I know your comments were not pertaining directly to Red Hat, and our XFree86 releases, however I thought that my comments might help others to understand the two applications a bit better that you pointed out, and at least why they are not present in Red Hat OS distributions any longer. That can help to understand also why neither application is part of XFree86 itself directly, and neither application is ever likely to be part of XFree86 in the future, as there is really no good technical reason for them to exist anymore. Nonetheless, this is the open source community, and anyone sufficiently motivated enough, can take either utility and revitalize them for their own purposes. Why when i go to Windows the first time, it goes in a low resolution and frequency and no in XFree ??. Windows starts up generally in 800x600 nowadays (XP). It uses a special driver Microsoft supplies called VGASAVE. I'm not completely at understanding at what this driver is doing specifically, however I believe that it is more or less a VESA BIOS driver, which can fallback to VGA mode if need be, and might possibly have special code in it for certain other hardware. It's more or less a failsafe driver which is good enough in order for a proper native driver to be installed for the video hardware in the system. When you boot into 'safe mode', this is the driver Windows uses. XFree86 could benefit also from having such a driver of course, and the vesa driver is probably the closest thing to such that exists in XFree86 currently. The vesa driver however requires a non-broken VESA BIOS in order to work correctly, and judging by the
[XFree86] can't ping to local host when set default gateway
Sorry, forgot something very important: If we delete the default gateway, we can ping the localhost successfully: #route del default gw 192.168.0.1 #ping localhost ... OK ... The following is the original e-mail: I am making a Java application on top of a Samsung ARM embedded platform. I can not ping the local host when trying to reach an internet address when set the default gate way to 192.168.0.1, the shell says, #ping localhost unknown host but it is strange enough that ping to 127.0.0.1 is ok. Since the X-server need to use localhost to get to the local machine, this becomes a very big problem. I have filled the /etc/hosts file with the following line, 127.0.0.1 localhost.localdomain localhost and in the /etc/host.conf, ... order hosts ... I found the named is missing in my system, could this possibly be the reason? Then how can I find it? regards _ Do You Yahoo!? http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cn_user_profile_study_dec2003 ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] cant get a crystal scan monitor to work
I've successfully installed RedHat 9, but on bootup I get a message about not being able to start the xserver, then it leaves me with a text window. Linux seems to be functioning ok from there. The video card (Trio 32/64) was recognized during the installation, and the monitor (Gateway Crystal Scan 1024 NI) I found in the list provided (I was surprized). Once I selected this, the panel with the scan frequencies showed values that more or less agreed with the manual I have for the monitor. The installation guide says I'll get a gui to help me set preferences - but I never get one. I've tried editing the XF86Config file to tell it to use the vesa driver instead of the S3 -- but it still fails. I also have Windows XP installed, and the monitor works fine there. What I think is happening, from the messages I get, is that the configurator finds the card ok, but it gets no answer back from the monitor (it being so old that it doesn't respond?). It then creates a default configuration file and tries again, to no avail. I think it is a bug that there seems to be no way to force the server to use the monitor I told it to use and not probe to see if I got it right. I have the log file, but somewhere between getting it on floppy and viewing it from Windows, it seems to have lost the line breaks. I enclose it anyway, in hopes that it is useful as is. The troubles are shown, of course, near the end: Primary Device is: (WW) s3: No matching Device section for instance (BusID PCI:0:8:0) found it repeats that many times as it steps throught the addresses down to (BusID PCI:9:19:0) Then (EE) No devices detected. Fatal server error: No screens found Hopefully, you can suggest to me a way around this? XFree86.0.log Description: Binary data
Re: [XFree86] Re: Re: Improvement
- Original Message - From: Mike A. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 18, 2004 5:44 PM Subject: [XFree86] Re: Re: Improvement So, Xconfigurator wont be coming back in our OS at least, however the source code is dual licensed GPL and MIT, so anyone can hack at it if they desire. If someone in the OSS community is interested in any way of rekindling Xconfigurator as a sourceforge or other project, feel free to contact me about this, and I don't think there will be any problem reassigning the source code to someone else. ;o) Be sure to actually LOOK at the sources first before committing to such an effort however, and make sure you've got a barf bag handy. ;o) This is an interesting idea. A sourceforge project would be a good thing ( with Xconfigurator or a new tool). That can help to understand also why neither application is part of XFree86 itself directly, and neither application is ever likely to be part of XFree86 in the future, as there is really no good technical reason for them to exist anymore. Nonetheless, this is the open source community, and anyone sufficiently motivated enough, can take either utility and revitalize them for their own purposes. There is user´s interest about it . See http://wiki.debian.net/index.cgi?DebianDesktop Now, my screen is black, without Xwindow. Why ??. When I could see it in Knoppix LiveCD without problems ??. :? I think the problem is the monitor frequency, but not sure... I would like to try to change the frequency ( with a help tool that automatically restore to the last value if I don´t press the OK key in a popup window in a certain time after the changes ). This is newbie-proof, isn´t it ?? ( one uses it in Windows too ;) Why when i go to Windows the first time, it goes in a low resolution and frequency and no in XFree ??. Windows starts up generally in 800x600 nowadays (XP). It uses a special driver Microsoft supplies called VGASAVE. Good thing to imitate ;) I'm not completely at understanding at what this driver is doing specifically, however I believe that it is more or less a VESA BIOS driver, which can fallback to VGA mode if need be, and might possibly have special code in it for certain other hardware. It's more or less a failsafe driver which is good enough in order for a proper native driver to be installed for the video hardware in the system. That´s what I need for my first installation. Later, I can use another driver... When you boot into 'safe mode', this is the driver Windows uses. XFree86 could benefit also from having such a driver of course, and the vesa driver is probably the closest thing to such that exists in XFree86 currently. The vesa driver however requires a non-broken VESA BIOS in order to work correctly, and judging by the large number of vesa driver user's bug reports I see, there are numerous broken BIOSes out there which make it difficult to have a failsafe driver. I believe it would be possible to fork the vesa driver into a new driver named failsafe or somesuch, which uses VESA VBE by default, but gets special hacks put in place for systems that are reported to not work, but workarounds can be found, and detected by PCI ID and other mechanisms. I'd like to at least experiment with this in the future to see if it is a crazy idea or not. Go ahed with it. You are taking Linux to a next step forwards. If everything is OK (after installation = first time) I can change the resolution, frequency and so on from the same Gnome or another desktop manager. I suggest try ( during installation) by default the 800X600 mode and a low refresh frequency ( if there is not plug and play autodetection). I don't disagree, however in order for it to work on _all_ video hardware, including hardware there are no drivers for, and hardware there are drivers for, but the drivers may be buggy, thus preventing the user from using X from the start, a new driver is required, which can provide minimal unaccelerated 2D video using VESA VBE and other fallbacks. Without that, it's just a pipe dream. I agree. (perhaps in the near future I am going to change to redhat ;) Regards. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: Re: Re: Improvement
On Sun, 18 Jan 2004, Pedro M. wrote: the sources first before committing to such an effort however, and make sure you've got a barf bag handy. ;o) This is an interesting idea. A sourceforge project would be a good thing ( with Xconfigurator or a new tool). Ah, so you haven't looked at the Xconfigurator source code yet. ;o) Nonetheless, this is the open source community, and anyone sufficiently motivated enough, can take either utility and revitalize them for their own purposes. There is user´s interest about it . See http://wiki.debian.net/index.cgi?DebianDesktop I see goals of having a friendly useable desktop there, not interest in someone bringing XF86Setup or Xconfigurator back from the dead. ;o) Now, my screen is black, without Xwindow. Why ??. When I could see it in Knoppix LiveCD without problems ??. :? Insufficient information to draw any conclusions... ;o) I think the problem is the monitor frequency, but not sure... I would like to try to change the frequency ( with a help tool that automatically restore to the last value if I don´t press the OK key in a popup window in a certain time after the changes ). This is newbie-proof, isn´t it ?? ( one uses it in Windows too ;) Some people or distributions might be interested in following that approach perhaps. That isn't user friendly however. A user friendly system would have monitors that just worked, requiring zero user intervention or configuration. Any monitor metadata needed for configuration would be supplied by the system (or manufacturers) and included with the OS (or driver updates), just as it is done in Windows. You (and others) may want to have a dialog for punching in this information indefinitely perhaps. Personally, I want to see the problem solved on a higher level, and be automatic, thus having users not need to know anything about their monitor other than how to turn it on. Why when i go to Windows the first time, it goes in a low resolution and frequency and no in XFree ??. Windows starts up generally in 800x600 nowadays (XP). It uses a special driver Microsoft supplies called VGASAVE. Good thing to imitate ;) I agree. I'm not completely at understanding at what this driver is doing specifically, however I believe that it is more or less a VESA BIOS driver, which can fallback to VGA mode if need be, and might possibly have special code in it for certain other hardware. It's more or less a failsafe driver which is good enough in order for a proper native driver to be installed for the video hardware in the system. That´s what I need for my first installation. Later, I can use another driver... Indeed, that is what I'd like to see in the future. The problem is a complex one however to solve. There is so much video hardware out there, that it is impossible to test it all. All a vendor such as us can do, is make changes to our infrastructure and defaults, release beta OS releases, get feedback from users and try to fix things in time for the final OS release. That isn't good enough though, because what's more likely to happen, is that once the OS is released, 100 times as many people use it, find problems that didn't turn up in beta testing or internal testing, and then they wonder why it doesn't work. So I'd like to see a failsafe driver in the future, but I'm not sure what the best approach is to create one in an evolutionary manner, rather than switchover overnight. Also, such a driver would need to exist for x86, ia64, AMD64, ppc, ppc64 for us, and also Alpha, sparc and other systems to be useful across the board. That complicates things a bit. I'd focus on x86 and AMD64 at first, and add bits to other architectures over time, in order to make the problem sanely approachable. I believe it would be possible to fork the vesa driver into a new driver named failsafe or somesuch, which uses VESA VBE by default, but gets special hacks put in place for systems that are reported to not work, but workarounds can be found, and detected by PCI ID and other mechanisms. I'd like to at least experiment with this in the future to see if it is a crazy idea or not. Go ahed with it. You are taking Linux to a next step forwards. Well, it wouldn't be Linux specific per se. It'd be OS neutral more or less, but it would have some architectural ties likely. I'd like to see some kind of driver emerge that is a superset of the vesa driver. I might fiddle with it myself over time as people report problems in the vesa driver to us, although I dont think such hacks belong in the vesa driver itself per se. as that would clutter the existing driver and go against it's purpose IMHO. But a driver based upon it, which gets hacked up over time might suffice. ;o) Take care, TTYL -- Mike A. Harris ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Bad points on screen
Which graphics card is the screen shot from? It looks like a driver bug or bad video ram, but I'm not aware of any nv driver bugs like that, so I would guess that your video card is old and flaking out. I assume it goes away if you disable acceleration with Option ShadowFB in the Section Device of the XF86Config file? Mark. On Sun, 18 Jan 2004, [iso-8859-2] Jakub Hodaò wrote: I have a problem !!! First please see to a screenshot. Problem is in bad coloured poits in screen. Its like as site of bad coloured points in screen. This points is some times repaired and create in new location. Refreshing off screen do nothing. I tested this problem on different hardware combination e.g. Nvidia Riva 128ZX, RIVA TNT2 (grafic adapters); ADI microscan 4G, Hyundai Image Quest Q790 (monitors). 0nly one component is same : Motherboard MSI 6338 LE5. With different distribution Mandrake 9.0 9.2 and Knoppix 3.3. Different grafic drivers xfree86 nv driver and original nvidia driver. With different desktops KDE GNOME ICEWM. Please help me, because I dont know what is it Jakub Hodaò [EMAIL PROTECTED] Licitovat nejvyhodnejsi nabídku je postavene na hlavu! Skoda Octavia nyni se zvyhodnenim az 90.000 Kc! http://ad2.seznam.cz/redir.cgi?instance=69100%26url=http://www.skoda-auto.cz/action/fast ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Re: Re: Re: Improvement
- Original Message - From: Mike A. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 18, 2004 7:23 PM Subject: [XFree86] Re: Re: Re: Improvement On Sun, 18 Jan 2004, Pedro M. wrote: Some people or distributions might be interested in following that approach perhaps. That isn't user friendly however. A user friendly system would have monitors that just worked, requiring zero user intervention or configuration. Any monitor metadata needed for configuration would be supplied by the system (or manufacturers) and included with the OS (or driver updates), just as it is done in Windows. You (and others) may want to have a dialog for punching in this information indefinitely perhaps. Personally, I want to see the problem solved on a higher level, and be automatic, thus having users not need to know anything about their monitor other than how to turn it on. There is two different ways to it : - The people with some computeres that want to use Linux. They cannot use this automatic configuration and they couldn´t know about linux now :( - Follow another standard for a full automated user-friendly installation/configuration. This can be stablish from now, so the next computers can follow this good standard. Unfortunatelly, I think one have to follow the two ways. I love the automated installation idea. So go ahead with it. On the other hand, I was thinking about another problem with the desktop : the keyboard / language. Thinking about automated installation, I would like to see the keyboard talking to the operating system ( symbolically, of course ) and saying : I am a keyboard and my ID is KB_ES_es (http://en2.wikipedia.org/wiki/Language_code ). In this way, I wouldn´t have to type, i.e., the cheatcode knoppix lang=es VGASAVE. Good thing to imitate ;) I agree. I have included more links in http://wiki.debian.net/index.cgi?XFreeCommon and information in http://en.wikipedia.org/wiki/VGASAVE Take care, TTYL Good work. All the best. Pedro. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] RE: Hi
? Eh? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, January 18, 2004 9:12 PM To: [EMAIL PROTECTED] Subject: Hi Test =) pmcnkpggspflu -- Test, yep. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] seeking advice
I installed Mandake linux 9.0 which ships with xfree86(version4.2.1) .I have a 15 inch. color monitor(mikrotek model:digisync) with max. resolution 1024x768 @60 hz(vert.) (hfreq:30-55khz,vfreq:50-120hz,display area:260mm(H)x195mm(v))and an intel845 machine(pentium 4) . Now the X-server refuses to come up .I send along full output from X-server and the Xf86config file. Please suggest. (mail me at :[EMAIL PROTECTED] or [EMAIL PROTECTED]) X-server output: XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-23mdkenterprise i686 [ELF] 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: Mon Jan 19 04:31:18 2004 (==) Using config file: /etc/X11/XF86Config-4 Using vt 7 (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found 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] XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. XF86Config : # File generated by XFdrake. # ** # Refer to the XF86Config man page for details about the format of # this file. # ** Section Files # Multiple FontPath entries are allowed (they are concatenated together) # By default, Mandrake 6.0 and later now use a font server independent of # the X server to render fonts. FontPath unix/:-1 EndSection Section ServerFlags #DontZap # disable CrtlAltBS (server abort) AllowMouseOpenFail # allows the server to start up even if the mouse doesn't work #DontZoom # disable CrtlAltKP_+/KP_- (resolution switching) EndSection Section Module Load dbe # Double-Buffering Extension Load v4l # Video for Linux Load extmod Load type1 Load freetype Load glx # 3D layer EndSection Section InputDevice Identifier Keyboard1 Driver Keyboard Option XkbModel pc105 Option XkbLayout us Option XkbOptions EndSection Section InputDevice Identifier Mouse1 Driver mouse Option Protocol PS/2 Option Device /dev/psaux Option Emulate3Buttons Option Emulate3Timeout 50 EndSection Section Monitor Identifier monitor1 VendorName Generic ModelName 1024x768 @ 60 Hz HorizSync 31.5-48.5 VertRefresh 50-70 # Sony Vaio C1(X,XS,VE,VN)? # 1024x480 @ 85.6 Hz, 48 kHz hsync ModeLine 1024x48065.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync # TV fullscreen mode or DVD fullscreen output. # 768x576 @ 79 Hz, 50 kHz hsync ModeLine 768x576 50.00 768 832 846 1000 576 590 595 630 # 768x576 @ 100 Hz, 61.6 kHz hsync ModeLine 768x576 63.07 768 800 960 1024 576 578 590 616 EndSection Section Device Identifier device1 VendorName Intel Corporation BoardName Intel 845 Driver i810 Option DPMS EndSection Section Screen Identifier screen1 Device device1 Monitor monitor1 DefaultColorDepth 24 Subsection Display Depth 8 Modes 800x600 640x480 EndSubsection Subsection Display Depth 15 Modes 800x600 640x480 EndSubsection Subsection Display Depth 16 Modes 800x600 640x480 EndSubsection Subsection Display Depth 24 Modes 800x600 640x480 EndSubsection EndSection Section ServerLayout Identifier layout1 InputDevice Keyboard1 CoreKeyboard InputDevice Mouse1 CorePointer Screen screen1 EndSection
