Barton C Massey wrote:
> In message <4c406a89.7080...@oracle.com> you wrote:
>> lbxproxy - calls xtrans directly since it's a X11 proxy, plus, it's
>> LBX, so it's just special anyway. (Also, since Xorg no
>> longer supports LBX, not widely used anymore.)
>
> Why do we ev
- Message d'origine -
> > Keeping in mind that things like GTK, Qt
> > and the likes are intended to *hide* the underlying windowing system, most
> > out there applications do not actually use Xlib directly at all.
>
> Unfortunately, a lot of the toolkits exposed Xlib API so that apps could
Non-legacy access lock is introduced, in addition to current
legacy access lock ("lega_locks"), for performance improvement
as most graphics operations after session starts do non-legacy
accesses which do not need to block themselves.
Legacy accesses are represented by "io" and "mem". Non-legacy
a
Mark Kettenis wrote:
>> From: Alan Coopersmith
>> But every app we port ourselves gives us more insight into what is
>> needed to port apps, and figure out how to make it easier for
>> authors/maintainers of the much more complicated apps out there in
>> the rest of the world.
I also should hav
On Fri, Jul 16, 2010 at 05:13:34PM +0200, Mark Kettenis wrote:
> > Date: Fri, 16 Jul 2010 07:39:16 -0700
> > From: Alan Coopersmith
> >
> > I suppose I left out my thinking about why it's useful to port the
> > X.Org apps to xcb. Clearly the mainstream distros are going to have
> > to ship libX1
Previous code assumed we were always 32bpp, so root window paint walked
off the end of the XImage and things went boom.
Signed-off-by: Adam Jackson
---
hw/kdrive/ephyr/ephyr.c |3 ++-
hw/kdrive/ephyr/hostx.c |7 ---
hw/kdrive/ephyr/hostx.h |3 ++-
3 files changed, 8 insertions(+)
Twas brillig at 19:00:32 16.07.2010 UTC+01 when jcris...@debian.org did gyre
and gimble:
JC> The following changes since commit
a2c13f0d6548310e3cd115cf486d3e43edf23dcc:
JC> Bump to version 1.8.99.905 (1.9 RC5) (2010-07-14 12:57:29 -0700)
JC> are available in the git repository at:
JC>
Hi,
Another cleanup in the rootless code..miext/rootless contains the last calls
to compatibility wrapper fbCopyRegion().
This patch updates to the new function...
--- ./miext/rootless/save_rootlessWindow.c 2010-06-06
06:21:44.0 +0100
+++ ./miext/rootless/rootlessWindow.c 2010-06-0
On 2010-07-16 14:00, Julien Cristau wrote:
> The transformation is mostly straightforward. One note though: Xephyr
> used XCheckTypedWindowEvent to bundle expose event processing; I don't
> know how to do that with xcb, so it's removed.
The simple version that gets most of the way there is (rough
On Tue, 2010-07-13 at 08:54 -0700, Aaron Plattner wrote:
> > This driver only configures against xserver 1.2 or higher.
> > Servers 1.2 and higher always include randr 1.2 modes code.
> > Therefore BUILD_XMODES will never be set to "yes".
>
> Fair enough. If anyone needs to be able to build the
This was used at one point in time to backport the modes code from server
1.3 to server 1.2. When the tarball was created, whatever modes code
was on the developer disk was included.
The server 1.2 as shipped in the tarball on the web does not contain the
modes code. It was added just after and fo
Hi,
I've been trying to port Xephyr to xcb instead of Xlib, with an eye to
getting that upstream for 1.10, so would appreciate some eyes on it :)
I've split up the change in several commits (using libX11-xcb in the
intermediate ones) so I could test changes independently, but I'm happy
to squash
On Fri, 16 Jul 2010 15:58:21 +0100, Daniel Stone wrote:
> Mm, there's a lot in xcompmgr that makes it a great example of how not
> to design a compositing manager. Unless you don't care in the least
> about efficiency or aesthetics (which is sort of the point of a
> compmgr).
xcompmgr was writt
Update the sun_mouse devPrivates code to conform to the new API
(introducted by commit faeebead7bfcc78535757ca7acc1faf7554c03b7)
that requires the PrivateKey to be registered.
See BUG 29049.
Signed-off-by: Patrick E. Kane
---
src/sun_mouse.c | 12
1 files changed, 12 insertions(+
Rémi Denis-Courmont wrote:
> Most of "the much more complicated apps" use X through some kind of UI
> toolkit framework. So I would guess that porting one of those frameworks is
> what's most "needed to port apps".
Absolutely - one of the clear lessons I learned with the xwininfo port was
that ou
On Fri, Jul 16 2010, Owain Ainsworth wrote:
> There is a port of libXft to xcb. I have been meaning to try and get it
> commited to git for a while now (It is not my work). The only link I can
> find is:
>
> http://gtk-xcb.svn.sourceforge.net/viewvc/gtk-xcb/libXft/
>
> Last I looked (a while ago)
Hello,
On Fri, 16 Jul 2010 07:39:16 -0700, Alan Coopersmith
wrote:
> But every app we port ourselves gives us more insight into what is needed
> to port apps, and figure out how to make it easier for
authors/maintainers
> of the much more complicated apps out there in the rest of the world.
On Fri, Jul 16, 2010 at 07:19:53AM -0700, Alan Coopersmith wrote:
> These depend on libXft, and I'm not sure what to do about that in a xcb
> port:
There is a port of libXft to xcb. I have been meaning to try and get it
commited to git for a while now (It is not my work). The only link I can
find
On Fri, Jul 16, 2010 at 06:10:11PM +0300, Tiago Vignatti wrote:
> On Fri, Jul 16, 2010 at 03:47:35PM +0200, ext Michael Olbrich wrote:
> > When configured with --disable-mitshm the symbols declared in shmint.h
> > do not exist. By guarding the include with '#ifdef MITSHM' these
> > symbols are skip
> Date: Fri, 16 Jul 2010 07:39:16 -0700
> From: Alan Coopersmith
>
> I suppose I left out my thinking about why it's useful to port the
> X.Org apps to xcb. Clearly the mainstream distros are going to have
> to ship libX11 until approximately the end of time_t - there's just
> too many thousands
On Fri, Jul 16, 2010 at 03:47:35PM +0200, ext Michael Olbrich wrote:
> When configured with --disable-mitshm the symbols declared in shmint.h
> do not exist. By guarding the include with '#ifdef MITSHM' these
> symbols are skipped when generating sdksyms.c with --disable-mitshm.
>
> Signed-off-by:
On Fri, Jul 16, 2010 at 05:32:32PM +0300, Tiago Vignatti wrote:
> On Fri, Jul 16, 2010 at 04:24:04PM +0200, ext Vincent Torri wrote:
> > On Fri, 16 Jul 2010, Alan Coopersmith wrote:
> > > Given what I learned on the xwininfo port I took a quick pass across
> > > the rest of the X.Org app/* modules
On Mon, Jul 12, 2010 at 07:04:11PM +0200, ext Eamon Walsh wrote:
> On 07/05/2010 09:21 AM, Vignatti Tiago (Nokia-MS/Helsinki) wrote:
> >
> > So I disabled XACE here in my machine and now my static analyzer is accusing
> > ~100 pieces of deadcode. That's because we have XaceHook everywhere and,
>
Vincent Torri wrote:
> On Fri, 16 Jul 2010, Alan Coopersmith wrote:
>> At least at a quick glance, I think these could be fairly straightforward
>> to port to XCB, though whether it's worth the effort for all of them is
>> debatable:
>>
>>backlight, ico, xcmsdb, xcompmgr, xdriinfo, xhost, xinit
On Fri, 16 Jul 2010, Tiago Vignatti wrote:
On Fri, Jul 16, 2010 at 04:24:04PM +0200, ext Vincent Torri wrote:
On Fri, 16 Jul 2010, Alan Coopersmith wrote:
Given what I learned on the xwininfo port I took a quick pass across
the rest of the X.Org app/* modules to see what it would take to
When configured with --disable-mitshm the symbols declared in shmint.h
do not exist. By guarding the include with '#ifdef MITSHM' these
symbols are skipped when generating sdksyms.c with --disable-mitshm.
Signed-off-by: Michael Olbrich
---
hw/xfree86/loader/sdksyms.sh |2 ++
1 files changed,
On Fri, Jul 16, 2010 at 04:24:04PM +0200, ext Vincent Torri wrote:
>
>
> On Fri, 16 Jul 2010, Alan Coopersmith wrote:
>
> > Given what I learned on the xwininfo port I took a quick pass across
> > the rest of the X.Org app/* modules to see what it would take to port
> > each to xcb.
> >
> > I am
On Fri, 16 Jul 2010, Alan Coopersmith wrote:
Given what I learned on the xwininfo port I took a quick pass across
the rest of the X.Org app/* modules to see what it would take to port
each to xcb.
I am *not* volunteering to do these all, just offering some insight into
which are going to be e
Given what I learned on the xwininfo port I took a quick pass across
the rest of the X.Org app/* modules to see what it would take to port
each to xcb.
I am *not* volunteering to do these all, just offering some insight into
which are going to be easier/harder/not possible and hoping that others
w
The XI2 protocol supports per-axis modes, but the server so far does
not. This change adds support in the server.
A complication is the fact that XI1 does not support per-axis modes.
The solution provided here is to set a per-device mode that defines the
mode of at least the first two valuators (X
XI2 allows for input event valuators to be masked. The current input
module API only allows for ranges to be specified. This fixes all
internal plumbing to use masks instead of ranges, and adds "M"
mask versions of xf86Post*Event() functions.
Signed-off-by: Chase Douglas
---
Xext/xtest.c
Hi Tim,
On Thu, Jul 15, 2010 at 11:26:25PM +0200, ext Tim HRM wrote:
>
> Yeah, we had a couple of issues that led
> to using Xfbdev when we started this over a year ago with the HTC
> Kaiser. Mostly that the kernel trees we were working for were
> designed for Android and the graphics hardware i
Hi,
Just tried the opposite in Xming (i.e. #undef ROOTLESS_PROTECT_ALPHA) and
can't see any difference in rootless modes.
But my tests are probably not good enough and I don't understand the
rootless code deep enough :)
I can't therefore see why the #if defined(__CYGWIN__) || defined(WIN32)
versi
On Fri, 2010-07-16 at 01:28 +0200, ext Peter Hutterer wrote:
> On Wed, Jul 14, 2010 at 11:26:43AM +0300, Oliver McFadden wrote:
> > This is very similar to the RunFromSmartParent (implicit) option, except
> > we do not send the signal to our parent process, but our own process
> > instead, and that
34 matches
Mail list logo
