[XFree86] tienes un descto de.....
20% en chocolates havanna
02-2475777
y por solo 6000 adicionales lleve 24 rosas ecuatorianas en
Caja:
Envios a las Condes y Vitacura Gratis
Cotice
Aqui
Envios a todo chile via
Lancourier
solo
por 4500 adicionales, finos bombones havanna
__
Si no quiere recibir nuestras ofertas,
haga click aqui
Acatando la nueva Ley del Consumidor
Nº 19.496 y su modificación Nº 19.955 del 2004,en su Artículo 28b, donde
regula el envío de correos electrónicos("Toda comunicación promocional o
publicitaria enviada por correo electrónico deberá indicar la materia o asunto
sobre el que versa,la identidad del remitente y contener una dirección
válida a la que el destinatario solicite la suspensión de los envíos")
[XFree86] The summary
ALERT!!!This e-mail contained one or more infected files.The following attachments were infected and have been repaired:No attachments are in this category. The following infected attachments were deleted:No attachments are in this category. The following infected attachments were blocked because of Mail Policy violations:1. account_info.zip: Mail Policy Block (Attachment Name) You may wish to contact the sender to notify them about their infected file(s).Thank you Original message text follows Response
[XFree86] Encrypted document
Check attached file for details.
[XFree86] Changes..
Please, have a look at the attached file.
[XFree86] Re: Document
Check attached file.
Re: [XFree86] Red Hat help
Only if it's a question about XFree86. This is not a good place for Red Hat or general Linux questions. Mark. On Wed, 24 Aug 2005, Daniel Bonnici wrote: Is XFree86 the correct place to look for help with an old version of Red Hat? Thanks: Daniel Bonnici -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.15/81 - Release Date: 8/24/05 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 05/08/25 06:27:52 Log message: Driver cleanups Modified files: xc/programs/Xserver/hw/xfree86/drivers/ark/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/ati/: radeon_driver.c xc/programs/Xserver/hw/xfree86/drivers/chips/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/cirrus/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/fbdev/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/glide/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/glint/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/i128/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/i740/: i740_driver.c xc/programs/Xserver/hw/xfree86/drivers/mga/: Imakefile mga_esc.c xc/programs/Xserver/hw/xfree86/drivers/neomagic/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/nsc/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/s3/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/savage/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/sis/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/tseng/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/v4l/: Imakefile xc/programs/Xserver/hw/xfree86/drivers/vesa/: Imakefile vesa.h xc/programs/Xserver/hw/xfree86/drivers/via/: Imakefile via_driver.c xc/programs/Xserver/hw/xfree86/drivers/xgi/: Imakefile Revision ChangesPath 1.9 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/ark/Imakefile 1.129 +1 -11 xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 1.35 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/chips/Imakefile 1.36 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/cirrus/Imakefile 1.13 +3 -5 xc/programs/Xserver/hw/xfree86/drivers/fbdev/Imakefile 1.10 +4 -7 xc/programs/Xserver/hw/xfree86/drivers/glide/Imakefile 1.44 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/glint/Imakefile 1.8 +3 -3 xc/programs/Xserver/hw/xfree86/drivers/i128/Imakefile 1.54 +1 -3 xc/programs/Xserver/hw/xfree86/drivers/i740/i740_driver.c 1.53 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/mga/Imakefile 1.5 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/mga/mga_esc.c 1.17 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/neomagic/Imakefile 1.10 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/nsc/Imakefile 1.15 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/s3/Imakefile 1.13 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/savage/Imakefile 1.37 +2 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/Imakefile 1.24 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/tseng/Imakefile 1.8 +3 -4 xc/programs/Xserver/hw/xfree86/drivers/v4l/Imakefile 1.10 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/vesa/Imakefile 1.16 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.h 1.12 +2 -3 xc/programs/Xserver/hw/xfree86/drivers/via/Imakefile 1.39 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/via/via_driver.c 1.2 +1 -2 xc/programs/Xserver/hw/xfree86/drivers/xgi/Imakefile ___ Cvs-commit mailing list Cvs-commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: Inter-module compatibility
On Sat, 20 Aug 2005, Marc Aurele La France wrote: Now, it's not my purpose here to get into these motivations, but reworking these structures would have consequences, one of which I am unsure how to deal with. At minimum, what I need to do is ... a) prevent drivers compiled with the current vbe.h from using a vbe module created with the new vbe.h; and b) prevent drivers compiled with the new vbe.h from using a vbe module created with the current vbe.h. I've prototyped a way of dealing with a). Basically, I'd have the vbe module's Setup() function call the common layer to associate a (potentiall extended) XF86ModReqInfo occurrence with the vbe module, which the loader would then use to check parent modules against. Dealing with b) is trickier. All I can think of right now would require changes to the way video drivers load the vbe module, something I'd like to stay away from, especially in the presence of vendor-provided source and/or binaries. b) could be handled by changing the drivers to specify a vbe module version requirement when loading the vbe module. I don't think that is unreasonable given that child module version checking is already a part of the loadModule interface. Yes. One issue with this is that it doesn't do anything for vendor-provided drivers. Vendors would need to handle the b) case in their drivers. Also, vbe.h could provide a macro to load the vbe module, the idea being to make the module control its own loading. If we were to start adding module interface version checking for other shared module interfaces, that would head off similar issues in the future. Yes, and how a module is loaded could be controlled by its main header, or something like xxxModule.h. The a) case can be made to fail cleanly by having the old names being functions that print out an informative message and exit. The b) case could be handled like this: #define VBEExtendedInit(a,b,c) \ (xf86LoaderCheckSymbol(newVBEExtendedInit) : \ newVBEExtendedInit(a,b,c) ? (FatalError(INFORMATIVE_MESSAGE), NULL)) However, I think it's better to control module loading from the module public headers, thus incorporating interface version checking with the interface definition and avoiding the need to resort to tricks like this. The attached (against current CVS) is a nearly finalised implementation of the above. I've tested this with various versions of the vbe and vesa modules, and it works as expected. However, what I have here is _very_ specific to the problem at hand, that being dealing with the consequences of changing the vbe InfoBlock structures. This means that I only changed those drivers (i810 (i830, actually), savage, sis, vesa and xgi) that actually care about the layout of these structures. For these drivers, both a) and b) are enforced. For other vbe'ing drivers, such as my own atimisc, b) is not enforced (good), but a) is, unnessarily. That's because, as I have it here, vbeSetup() doesn't have a reasonable way of detecting its parent module doesn't peek/poke into the changed structures. So, I'm left with an assymmetric implementation. The options, at this point, are ... 1) Leave this as is; 2) Change all vbe'ing drivers. This would put them all on the same footing WRT enforcing a) and b). 3) Make vbeSetup() smarter. One possibility here is to check version requirements only if the parent references, say, VBEGetModeInfo(), although this wouldn't work for the combined i810 module, where only the i830 code path looks into these structures. I don't have a strong preference, except to commit a finalised version of this change all in one go, to eliminate exposure. The more I think about this, the more I'm inclined to renege on my lack of preference. 3) would require the vbe module to know about a fairly specific aspect of driver internals. In 1), something akin to the reverse happens, i.e. the driver would need to be aware of what specifically in the vbe module became incompatible. This before even loading it. Design-wise, 2) is the sole alternative that preserves layering. Applying 2) to the more general problem of inter-module versioning also means that any incompatibility is to be considered as one of the entire module where it occurs, rather than of only part, or some aspect, of this same module. This, in retrospect, seems obvious. So, barring objections here, I'll be proceeding with 2). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply
Re: Some doubts in Xlib
Puneet Goel wrote: 1) While debugging I am seeing that dpy structure pointer is being passed by some calls. dpy intern contains 'buffer', 'bufptr' etc. While digging through the location pointed by 'buffer' and 'bufptr' the data is shown as \003\005 or \002 etc. What is the meaning of these values ? I was expecting buffer or bufptr to be some real data buffers being passed to Xserver but found something else. Any hints what are these ? What makes you believe that the buffer does not represent the data being passed to Xserver? What were you expecting to see? Many of the packets sent to the server are mouse position updates, which are not going to be neatly human-readable. -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
