Re: memory address of pixmap
Mark Vojkovich wrote: pPixmap-devPrivate is the pointer to the memory, but this is dynamic. Pixmaps get migrated back and forth between video and system ram. So you need to check it every time you reenter your code. oops. The bitblit routines are rather hairy to follow, so I hope you dont mind me also asking; what are the pitfalls of me creating a pixmap myself? The constraints are that I want to be able to allocate an offscreen memory chunk myself via xf86AllocateLinear, then create a pixmap around it, and then be able to use the accelerated bitblit routines via gc-ops-CopyArea() Is the process of creating an offscreen pixmap the hard way documented anywhere? Like a place for tips for 2d card driver writers? ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
fonttosfnt portability patch
Hi, Currently fonttosfnt doesn't compile on NetBSD, OpenBSD or Mac OS X (and probably others) because it depends on byteswap.h which is a linuxism. I've created Bugzilla #433 with a proposed patch. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Empreendedor com Internet
Empresa procura pessoas de perfil Empreendedor com Internet, para implantar e gerenciar estrutura comercial. Ganhos de até 80.000,00 ao ano. Visite: www.hipernegocio.net Elmer NGTCorp - Duvidas pelo email [EMAIL PROTECTED] Para ser removido de futuros correios, por favor, envie email para [EMAIL PROTECTED], com o assunto REMOVER. Obrigado. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fonttosfnt portability patch
MH Currently fonttosfnt doesn't compile on NetBSD, OpenBSD or Mac OS MH X (and probably others) because it depends on byteswap.h which is a MH linuxism. MH I've created Bugzilla #433 with a proposed patch. Thanks. Please see bugzilla for minor comment. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.99.7 and text inputs
On Sat, 28 Jun 2003, Andrew Bevitt wrote:
I just build the 4.3.99.7 snapshot this afternoon, and did not notice and
problems with the building process. X started normally and for a while
usage seemed normal.
But when I started up AMSN and tried to send someone a message, I
simply couldnt get any text to enter into the inpt box. I tried several WM's
and various tricks to make the chat window definately in focus. Nothing
made it work.
I just tried using GFtp aswell, and the same problem occurs on the
password input box but not on any other of the text input boxes. Which
leads me to believe that this maybe related to authenticated inputs or
something.
Does anyone have any ideas?
My latest CVS builds are doing something funny with text input too.
A couple of tk/tcl/wish clients aren't accepting keyboard input
into text boxes. At least one of these wish scripts works if run
on the same display, but from a remote machine with a different
version of X and wish, which leads me to suspect a problem in
the X client libraries.
% ldd /usr/bin/wish
libtk8.0.so = /usr/lib/libtk8.0.so (0x4001c000)
libtcl8.0.so = /usr/lib/libtcl8.0.so (0x400ba000)
libX11.so.6 = /usr/X11R6-v4/lib/libX11.so.6 (0x4011e000)
libdl.so.2 = /lib/libdl.so.2 (0x401d7000)
libm.so.6 = /lib/libm.so.6 (0x401dc000)
libc.so.6 = /lib/libc.so.6 (0x401f9000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
tkdiff (another wish script) and ical (another tcl/tk application)
are both happy to accept keystokes to control the program
('q' to quit for tkdiff, and ctrl-key sequences to cut/copy/paste
items in ical) but wont allow keystrokes to enter text.
% locale
LANG=en_GB
LC_CTYPE=en_GB
LC_NUMERIC=en_GB
LC_TIME=en_GB
LC_COLLATE=en_GB
LC_MONETARY=en_GB
LC_MESSAGES=en_GB
LC_ALL=
% uname -a
Linux ard 2.2.19-6.2.7 #6 Wed Jan 9 21:36:45 GMT 2002 i686 unknown
This is a Red Hat Linux 6.3 machine.
--
Andrew C. Aitchison Cambridge
[EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: memory address of pixmap
On Sat, 28 Jun 2003, Philip Brown wrote: Mark Vojkovich wrote: pPixmap-devPrivate is the pointer to the memory, but this is dynamic. Pixmaps get migrated back and forth between video and system ram. So you need to check it every time you reenter your code. oops. The bitblit routines are rather hairy to follow, so I hope you dont mind me also asking; what are the pitfalls of me creating a pixmap myself? The hardware won't be able to render to it. XAA only knows that it's a hardware surface because it allocated it. In the new XAA, it's the driver that does the allocation since there are problem with XAA trying to allocate it as it does currently. XAA doesn't know enough about the hardware contraints to do a good job of it. Also, they do need to get migrated between video ram and system memory. They can't stay in video ram when you switch VTs. The constraints are that I want to be able to allocate an offscreen memory chunk myself via xf86AllocateLinear, then create a pixmap around it, and then be able to use the accelerated bitblit routines via gc-ops-CopyArea() You'll never get this working properly. Even XAA can't use xf86AllocateLinear because it doesn't know about hardware alignment contraints. In XAA, the root window extends downward and offscreen pixmaps are just windows that are offscreen. There is no mechanism to take a linear allocation and make a hardware pixmap out of it. The XFree86 5.0 XAA deals with this by leaving it all to the driver. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re : 4.3.99.7 and text inputs
On 2003.06.28 02:45, Andrew Bevitt wrote: On Sat, 28 Jun 2003 04:49 am, E. ALLAUD wrote: On 2003.06.27 12:05, Andrew Bevitt wrote: Hey 0 I just build the 4.3.99.7 snapshot this afternoon, and did not notice and problems with the building process. X started normally and for a while usage seemed normal. But when I started up AMSN and tried to send someone a message, I simply couldnt get any text to enter into the inpt box. I tried several WM's and various tricks to make the chat window definately in focus. Nothing made it work. I just tried using GFtp aswell, and the same problem occurs on the password input box but not on any other of the text input boxes. Which leads me to believe that this maybe related to authenticated inputs or something. Does anyone have any ideas? I think I had been hit by that also : the work-around which worked for me was to disable XKEYBOARD extension. This is perhaps a bug? Bye Manu I tried adding Option XkbDisable to the Keyboard section of XF86Config and then restarting X but still had the problems as mentioned above. How did you disable XKEYBOARD extensions if different to how I did? No that's what I did, so I guess we have different problems :( Bye Manu pgp0.pgp Description: PGP signature
Re: Dell C400 fix applied to 855GM?
Newer BIOSes are supposed to provide a BIOS call which can be used to change the size of video RAM the BIOS knows about. Can you look at the vendor string if the BIOS in you lock file? How do I do this? where is the lock file? Is this a DELL provided one or one from Intel? I believe that the BIOS is a custom Dell one... CPUID in windows says: BIOS Brand: Dell Computer Corporation Version: A00 Date: 04/28/2003 I'm not sure if this is what you meant? I've talked to Intel about this and they say this should be fixed with an BIOS update. Hmm... do you think this will lead to Dell updating theirs? Thanks! Oliver ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: memory address of pixmap
Mark Vojkovich wrote: ... Even XAA can't use xf86AllocateLinear because it doesn't know about hardware alignment contraints. In XAA, the root window extends downward and offscreen pixmaps are just windows that are offscreen. There is no mechanism to take a linear allocation and make a hardware pixmap out of it. Well, I dont care too strongly about using xf86AllocateLinear myself. I just need some method of encapsulating (locked down) offscreen video memory, in a manner that I can also leverage the 2d hardware acceleration . Mostly just bitblits. I dont care too much about the other stuff; while it might be useful if available, it's not the crucial issue. XAACopyArea() seems to explicitly have code for the case of IS_OFFSCREEN_PIXMAP(pSrcDrawable) Do you have a suggestion for the best way my extension module could allocate an offscreen pixmap that would not get swapped out to system memory? Or, just faking out XAACopyArea() enough to work in most cases? Or even XAAInfoRecPtr-ScreenToScreenBitBlt() A related question: Is it reasonably valid to cheat the XAA routines, calling SetupForScreenToScreenCopy() SubsequentScreenToScreenCopy(pscrn, srcx,srcy, dstx, dsty,w,h) and make 'fake' srcx,srcy coordinates for my offscreen memory area? This has the disadvantage that I would have to allocate my related offscreen areas sparsely like visible windows, I think(?), but that would be acceptible to me. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.99.7 and text inputs
On Mon, 30 Jun 2003 09:32 am, [EMAIL PROTECTED] wrote: Did the log file say that it had actually been disabled? According to the XF86Config man page (of 4.3.0), this option should go in the ServerFlags section, which is where I have successfully used it before. You might want to try putting it in there. Yes I tried placing the option in both serverflags and in the keyboard section I tried passing booleans such as true false disable enable aswell and did not notice and difference in performance. I checked the log files just now aswell and found these two lines (**) Option XkbDisable (**) Xkb disabled So I would assume that it was disabled. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
