On Thu, 28 Aug 2003 12:47:26 +0200 Thomas Winischhofer <[EMAIL PROTECTED]>
(Bbabbled:
(B
(B> Carsten Haitzler (The Rasterman) wrote:
(B> > ah shared framebuffer. ok. then i can understand some of the "hurt" :)
(B> >
(B> >
(B> >>What values do you get on your hardware? (Unscaled only, t
On Fri, 29 Aug 2003, [utf-8] RafaÅ Rzepecki wrote:
> On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > What's a "normal" result for -aa24text on Intel hardware with, say,
> > nvidia or radeon?
> >
> > Anyone?
>
> Celeron Coppermine [EMAIL PROTECTED], NVidia TNT2 M64:
>
> 64000
On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > > What's a "normal" result for -aa24text on Intel hardware with, say,
> > > nvidia or radeon?
> > >
> > > Anyone?
>
On Friday 29 of August 2003 02:51, Rafał Rzepecki wrote:
> On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> > On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > > On Thursday 28 of August 2003 15:58, Thomas Winischhofer wrote:
> > > > What's a "normal" result for -aa24text on Intel h
On Friday 29 of August 2003 03:03, Rafał Rzepecki wrote:
> On Friday 29 of August 2003 02:51, Rafał Rzepecki wrote:
> > On Friday 29 of August 2003 02:34, Mark Vojkovich wrote:
> > > On Fri, 29 Aug 2003, [utf-8] Rafał Rzepecki wrote:
> > > > On Thursday 28 of August 2003 15:58, Thomas Winischhofer
Bryan W. Headley writes:
> >
> Well, if you are doing a switch/case on the Atom, this infers very
> strongly that you know upfront what every Atom could be for your
> decision tree. But if you don't care, you convert the Atom to a char*,
> display it, and maybe the string's meaning is impl
Carsten Haitzler (The Rasterman) wrote:
>>That is strange. Without acceleration, I get
>>
>>9.7
>>1.7
>>2.3
>>
>>Seems imlib uses the video RAM.
>
> definitely not. imlib2 only uses system ram - all its buffers are a direct
> result of malloc() :) imlib2 has no clue that video hardware exists :)
Hello,
scanning through the log of a XFree86 4.3.0 I found out that "ucs2any"
is invoked two times for each font at different stages of the build
process. Is that a known problem? While it isn't a big problem for
a fast x86 system it is quite painful on slower architectures because
it incr
Egbert Eich wrote:
Bryan W. Headley writes:
> Actually, it's worse than that: the kernel neither knows nor cares that
> the device mapped to pci:00/:00:1f.4/usb2/2-1/2-1:0 was a tablet
> of type XI_TABLET. If I'm lucky, it might think to pass the USB vendorID
> and productID which w
Matthias Scheler wrote (in a message from Friday 29)
> Hello,
>
> scanning through the log of a XFree86 4.3.0 I found out that "ucs2any"
> is invoked two times for each font at different stages of the build
> process. Is that a known problem? While it isn't a big problem for
> a fast x8
On Thu, 28 Aug 2003, Mark Vojkovich wrote:
> > > > It occurs to me that we should probably change XAA to flush CPU caches
> > > > just after calling the driver's Sync() function, and change mibank to do
> > > > the same after telling the driver to switch banks.
> > >That is a hardware issue a
On 28 Aug 2003, John Dennis wrote:
> 3) Would you really want caching on framebuffer memory in the presence
> of a graphics co-processor that can alter the memory independently of
> the cache?
Absolutely, _with_ the synchronisation mechanism XAA already provides.
Marc.
+
I've discussed XINPUT before, tried to fix some things, and
realized that the XFree86 XINPUT code needs a complete re-write.
It is particularly messed up for non-pointer devices. Jim
Gettys took over XFree86 XINPUT, and agreed that a re-write
is needed. I put off working on XINPUT until he got star
--- Thomas Winischhofer <[EMAIL PROTECTED]> a
écrit : > Carsten Haitzler (The Rasterman) wrote:
> >>That is strange. Without acceleration, I get
> >>
> >>9.7
> >>1.7
> >>2.3
> >>
> >>Seems imlib uses the video RAM.
> >
> > definitely not. imlib2 only uses system ram - all
> its buffers are a dire
--- "Bryan W. Headley" <[EMAIL PROTECTED]> a
écrit : > Egbert Eich wrote:
> > Bryan W. Headley writes:
>
> Sorry, just telling you how it is, now. hotplug
> listens to a kernel
> message layer, and invokes shell scripts in response
> to events. These
> scripts can load/unload kernel device d
emmanuel ALLAUD wrote:
Perhaps one of the problem of that approach is : if
the user booted up with all things alredy plugged in
how do we get all the devices IDs we need?
Moreover the lookup table and the parser can be quite
hairy but in a first try we can just do something
really simplistic, and c
On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote:
>I've discussed XINPUT before, tried to fix some things, and
>realized that the XFree86 XINPUT code needs a complete re-write.
>It is particularly messed up for non-pointer devices. Jim
>Gettys took over XFree86 XINPUT, and agreed that a re
I am using XFree86 4.3.0 on a Debian Sid system with kernel 2.6.0-test4.
Before I file a formal bug, I wanted to verify that it wasn't already fixed
in the CVS HEAD.
I have a Radeon M7. The XServer locks up the machine every now and then.
When it locks up, the machine will still repsond to ACPI ev
18 matches
Mail list logo
