2008/12/24 Rémi Cardona :
> Le 23/12/2008 23:56, Nikos Chantziaras a écrit :
>> Why not? I thought the x11-drm from git (that's x11-drm- in the
>> x11 overlay) was always the best way to test the latest code...
>
> Not anymore. Now the drm drivers are developed directly within the linux
>
Beso wrote:
> 2008/12/23 Barry Scott :
>
>> I have found the leak.
>>
>>
> isn't it simpler to update the xorg-server version?! 1.3 one is rather
> old and probably
>
I'm working on an embedded system which makes it a big problem to update
the Xorg server.
> a memory leak bug would have
'Twas brillig, and Colin Guthrie at 24/12/08 02:11 did gyre and gimble:
> Hi,
>
> Just built the 1.6 branch + recent mesa snapshot and other such stuff.
>
> It seems to be stable enough just now, but one thing that's been
> affected is how the mouse positions itself to top-left after a certain
Barry Scott wrote:
> I have found the leak.
>
> At line 202 in miext/cw/cw_ops.c we have:
>
Sorry this is not the leak. (I followed the wrong caller
of miRegionCreate).
The leak is coming from this call sequence:
#0 miRegionCreate (rect=0x0, size=0) at miregion.c:339
#1 0x0812ed4b in miRects
On Wednesday 24 December 2008, Dave Airlie wrote:
[...]
>> I found the one in xf86-video-radeonhd-1.2.4, and copied it to the src
>> tree beside the other .h files, and it built, and I've installed it and
>> running it, although not much is changed. glxgears is still moping along
>> at about 875
This is probably a very basic question, but it is important for me to know:
If I do an ordinary (non-accelerated) memcpy of a frame from system
memory to a buffer in AGP memory (allocated via DRI), is it any faster
than a (non-accelerated) memcpy of the exact same frame to a buffer area
in offs
Hello everyone,
I fiddled around a bit more with my Displaylink device, and here's what I
found so far (posted as a sort of reference, and maybe to help start a
discussion):
Content of transfers:
- All image data is sent as bulk transfers.
- The driver sends two big blocks during the setup pha
> - The key is likely 16 bytes, which are sent as a control transfer. They
> appear
> to be random, but the same 16-byte string can appear repeatedly, esp. if the
> device is initialized immediately after bootup. If these 16 bytes are equal,
> then all bulk transfers are also identical byte-for-
2008/12/24 Gene Heskett :
>>> But now this exposes a new problem I don't recall in these exact words,
>>> when I do a startx, it cannot load the kernel radeon module
>>> (this from the Xorg.0.log)
>
> Any comment on this?
...
> for the health & well being of an HD2400-Pro (rv610) card?
The direct
Hello Alan,
>> - The key is likely 16 bytes, which are sent as a control transfer. They
>> appear
>> to be random, but the same 16-byte string can appear repeatedly, esp. if the
>> device is initialized immediately after bootup. If these 16 bytes are equal,
>> then all bulk transfers are also ide
> so are the subsequent image blocks. However, when I change the background
> image and reboot the VM, I can get the same "key" at startup, but
> different image blocks. So I'm quite sure it can't be any kind of hash.
So both encrypted VNC or RDP variants are candidates. It doesn't sound
like VN
On Wed, Aug 6, 2008 at 15:30:09 -0700, Keith Packard wrote:
> On Wed, 2008-08-06 at 14:25 -0600, Pete Zaitcev wrote:
> > Hi All:
> >
> > What would it take to include the attached patch for dixfonts.c?
>
> Uh, you've uncovered a serious bug in DIX. The XSELinux patches tried to
> automatically
Colin Guthrie wrote:
> 'Twas brillig, and Colin Guthrie at 24/12/08 02:11 did gyre and gimble:
>
>> Hi,
>>
>> Just built the 1.6 branch + recent mesa snapshot and other such stuff.
>>
>> It seems to be stable enough just now, but one thing that's been
>> affected is how the mouse positions itse
hi Alex,
Because the flag exist in EDID, but some laptop can't provide EDID, how can we
know whether it support continuous frequency or not ?
Thanks
Ma Ling
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/x
14 matches
Mail list logo
