Re: How to convert the server time in xEvent to system time?
Am 11.08.2004 00:31:59 schrieb(en) Weidong Cui: Hi, There, xEvent.u.keyButtonPointer.time (aka 'server time'?), defined in X11/Xproto.h, indicates the number of milliseconds elapsed since the X server started. I want to convert it to an absolute time which then can be compared with times recorded by gettimeofday () in some other program. Unfortunately, after spending a lot of time, I still can't find out how to do it. If you happen to know how to do it, can you please tell me? Thanks a lot! Weidong Cui ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel I don't know much about this, but I would suggest, that you use the time-function to get the time in seconds. You divide the number of milliseconds to get seconds and then subtract the values. You get the time of the start of the X-Server in seconds. Maybe you can use this idea Oliver Welter ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: confucian
Hi. Do you know that you can get pre-approved 1.57% mortgage rate even with bad c r e d i t? Simply follow the link below and we will approve your application in several hours. No need to worry! Approve Me Now! crazy cygnus wax abetting. enunciate casebook plywood, breakoff wick cryptanalytic hecuba Follow the link above to get out instructions loan scatterbrain selfadjoint dumb. argumentative bromfield beer, dryden clout hath mountain columbus agglutinin or ineluctable. pedant perish prefab, intrusion hurty alfalfa brainstorm dear instinctual maestro giddap. archdiocese spaniard whatley, hank strongroom fruehauf apothegm incarnate chlorate archae pentagon. perilous tetravalent curvature, haplology camilla inaccurate adroit DC Enterpriseswhat're Paragon Towersdiagnosable 233 Needhamagamemnon Suite 300cocaine Newton MA 02164robbery
hi
hi, Feel younger and stonger and last longer, let me show you how. a href=http://qim.wpzza.us/hgh/?hpsales;show you now dus/a/font http://xfs.wpzza.us/hgh/?hpsales a href=http://ogs.wpzza.us/hgh/o.html;stop offerz/a ljs wns cpp azz jho ryv ema ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [directfb-dev] Re: blanking of non-refreshing windows
Quoting Michel Dänzer ([EMAIL PROTECTED]): On Thu, 2003-08-21 at 23:12, Andy Isaacson wrote: On Fri, Aug 15, 2003 at 12:06:18PM +0200, Michel Dänzer wrote: On Wed, 2003-08-13 at 16:29, Andy Isaacson wrote: I'm not familiar with how those two X servers operate, so could you help me out by explaining? How do they handle window obscures? How is it different from X11's BackingStore? I don't know a lot of details yet, but they indeed always keep the contents of windows around and composite the desktop with them (actually, they have another windowing system do this, but that's not the point). Seems to me you've got to break X11 semantics in order to do this: I suppose they must disable PartiallyObscured events, otherwise the hidden portion of the app windows won't get updated. Right, in XDirectFB overlapping top level windows don't obscure or expose each other. Each top level window has its own surface in (video) memory. After a bunch of updates done by the application, the screen region affected by these changes is recomposed by blitting the window surfaces to the layer's surface (screen). Alpha blended windows are blitted via TMU, at least with a Matrox. In other words, we already had windows being a texture three years ago, Longhorn has it now. (Personally, I'd consider even outdated window contents more useful than unrelated contents or none at all until the client handles the expose event?) There's no old content. Applications still draw to regions that are not visible to the user (yet). too often the BS pixmap is too old, and the X server writes it to the framebuffer only to have it overwritten by the app as soon as it's scheduled. Well, do you want the windows to be refreshed ASAP or not? :) I don't think this is a big deal as the windows will be kept in video RAM whenever possible. I want the window contents to be correct, or at least, innocuous. I agree that if the backing store is kept in the off-screen framebuffer the overhead is minimal; I don't think XFree86's BS implementation can do that. Right. I haven't noticed much difference in general with my every day apps, except that XDirectFB looks and feels snappier and smoother. That's because a) there are much less expose events an b) each single drawing operation is not immediately visible to the user. Therefor a clear plus some drawing appears at once. But it depends on the interactivity of the server and the client. It flickers rarely. In general I want the system to work correctly an in a performant manner even if the number of windows exceeds available off-screen framebuffer memory. It would be interesting how it performs in that case indeed; I don't expect it to be too bad though as it was quite usable even without any hardware acceleration. The surface manager of DirectFB kicks out older window surfaces if no free space is available. Only if many windows overlap while being transparent, it could slow down noticably, because all windows are needed to recompose the stack. But with a 32MB card I have space for many windows ;) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- Convergence GmbH ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
Thanks a bunch for the update Hope! In the mean time, I've resorted to using debian as the guest OS in VMWare, works out pretty nicely in fact. (I get to use the 802.11g card, and XP's suspend/hibernate/power management! =) -Oliver Hope Merritt wrote: All, The patches will not work do to a limitation in the Dell system BIOS and Intel VBIOS. Dell locks their pre-allocated (once called stolen) memory at 1MB and therefore you will be limited in modes on Linux since the VBIOS limits its modes to the amount of pre-allocated memory. Intel has implemented a workaround, but it would require Dell to implement one of Intel's latest VBIOS drops in there systems BIOS and then update the system BIOS. I would expect any 855 release of system BIOS from Dell in the next 2 months to have the VBIOS that allows the Xserver to report memory it allocated to the VBIOS and the modes could be adjusted. Best regards, Hope Merritt, III Intel Corporation Software Applications Engineer Desk: 916-356-0936 Text: [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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: Dell C400 fix applied to 855GM?
The fix was unsuccessful coming from one person on the Dell forums who tried it (I think some others are going to try it though - I posted it on the Gentoo forums). Thanks for your efforts... if another possible workaround surfaces, I'd be glad to give it a try (or find someone who will =). Another idea... if no software/driver workaround is possible and Dell refuses to update/fix their BIOS, is there any feasible way of modifying the BIOS independant of Dell? ie. grabbing the image file and finding where it specifies 832KB (or whatever it sets it to... 896 or something?) and changing that to around 8MB? I'm not sure if the BIOS could be interpretted or not though (seen in assembly - or just a bunch of bits). Is this possible?... legal? Definately risky, I know. -Oliver David Dawes wrote: On Thu, Jun 26, 2003 at 09:35:52AM -0500, Oliver Wong wrote: Hello all, I recently purchased a Dell D400, which suffers from a BIOS only allocating 1MB of legacy video memory (stolen memory) to the integrated graphics... I believe the Dell 500m and other 855GM laptops suffer from this as well. The BIOS also does not provide the appropriate mechanisms for the current drivers to change that. Researching, I found that the Dell C400 and other similar laptops had this problem too (with an older chipset), but a work around was written (by Abraham vd Merwe?). Does anyone know if a similar work around could be applied to the 855GM's? Or is the chipset radically different so that that fix will not work? That method didn't work on the test hardware I had access to when adding the 855GM support. The driver does implement a new method for informing the video BIOS about additional memory allocations, but I haven't seen any evidence of production hardware implementing it yet. You could try the attached patch, which should enable the old 830M method for all platforms, and let me know if it works. It's possible that Dell has the old method implemented in their video BIOS. If it doesn't work, you'll need to follow it up with Dell. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes biosmem.diffName: biosmem.diff Type: Plain Text (text/plain) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Dell C400 fix applied to 855GM?
Hello all, I recently purchased a Dell D400, which suffers from a BIOS only allocating 1MB of legacy video memory (stolen memory) to the integrated graphics... I believe the Dell 500m and other 855GM laptops suffer from this as well. The BIOS also does not provide the appropriate mechanisms for the current drivers to change that. Researching, I found that the Dell C400 and other similar laptops had this problem too (with an older chipset), but a work around was written (by Abraham vd Merwe?). Does anyone know if a similar work around could be applied to the 855GM's? Or is the chipset radically different so that that fix will not work? More info on the C400 is here: http://www.cse.unsw.edu.au/~chak/linux/c400.html Thanks! -Oliver Wong ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dell C400 fix applied to 855GM?
David Dawes wrote: On Thu, Jun 26, 2003 at 09:35:52AM -0500, Oliver Wong wrote: Hello all, I recently purchased a Dell D400, which suffers from a BIOS only allocating 1MB of legacy video memory (stolen memory) to the integrated graphics... I believe the Dell 500m and other 855GM laptops suffer from this as well. The BIOS also does not provide the appropriate mechanisms for the current drivers to change that. Researching, I found that the Dell C400 and other similar laptops had this problem too (with an older chipset), but a work around was written (by Abraham vd Merwe?). Does anyone know if a similar work around could be applied to the 855GM's? Or is the chipset radically different so that that fix will not work? That method didn't work on the test hardware I had access to when adding the 855GM support. The driver does implement a new method for informing the video BIOS about additional memory allocations, but I haven't seen any evidence of production hardware implementing it yet. You could try the attached patch, which should enable the old 830M method for all platforms, and let me know if it works. It's possible that Dell has the old method implemented in their video BIOS. If it doesn't work, you'll need to follow it up with Dell. Alright, thanks David. I haven't gotten my D400 in yet, but it should be arriving soon (expected delivery is tomorrow). Does anyone else have a D400 out there that could give this a try? Since I won't even have a linux distro on mine for a little while. -Oliver David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes biosmem.diffName: biosmem.diff Type: Plain Text (text/plain) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: key-bug?
I had the same problem, but I solved it with the changing of the keyboard-model: setxkbmap -model pc102 I also tried to change this in /etc/X11/XF6Config but it didn't worked. For some unexpected reason the X-Server doesn't pay attention to the config-file. I was not able to change the model or even the language. It refers to standard model pc101 everytime I start the X-Server. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
