With -Dlibwacom=false, an error occurs. It looks like it is because the
definition is inside "if have_libwacom".
I'd suggest a fix, but I have no experience with meson to know what the best
style would be.
meson --prefix=/usr --buildtype=release ../libinput-1.8.0 --libexecdir=/usr/lib
\
-Ddeb
On 07/22/2011 04:01 PM, Tiago Vignatti wrote:
> Hi all,
>
> I wanted to use an already existent library for logging; the first that came
> to my mind was one with syslog interface. I like because there is a lot of
> implementations around, it's simple and kinda flexible. For instance, I can
> g
I bring this up because it has been on my mind for a while and this is a good
opportunity to decide if we are doing what we want to and maybe improve the
underlying mechanisms.
There are a number of things that happen if the system has been 'idle' for some
period of time. Different parts of th
On 07/18/2011 07:17 AM, Corentin Chary wrote:
> On Mon, Jul 18, 2011 at 10:22 AM, Tiago Vignatti
> wrote:
>> On 07/18/2011 11:01 AM, laszlo.p.ag...@nokia.com wrote:
>>>
>>> Doesn't clock_gettime need -lrt? Otherwise (on Ubuntu at least) the linker
>>> will complain about an undefined reference i
On 05/25/2011 10:20 PM, Christopher Friedt wrote:
> Hi Marty,
>
> Thanks for your suggestion - I looked back in the wayland lists a bit
> and found Kristian's suggestion that libxkbcommon should be compiled
> with --with-xkb-config-root=/usr/share/X11/xkb (in my case). Now it
> doesn't fail, but
On 05/22/2011 10:01 AM, Christopher Friedt wrote:
> On Fri, May 20, 2011 at 11:00 AM, Doug Schaefer wrote:
>> Cool. What configure options did you use for mesa?
>
> ./configure --prefix=/usr --disable-glut --enable-gles2
> --disable-gallium-egl --with-egl-platforms=wayland,drm,fbdev
> --with-st
Mostly, it is identically equal to "remote Wayland protocol". Except that this
iSwifter thing is specific to remoting Flash applications.
Speaking of which there is a GSOC'11 proposal over on X.org to do the remote
Wayland protocol.
The parts about Lion taking over the world I am skeptical of
On 03/13/2011 09:33 AM, Matt Hoosier wrote:
> Hi,
>
> I ran into a link error when trying to compile the demos repository according
> to the instructions on the Building page:
>
> CCLD compositor
> libwayland-egl.so: undefined reference to `wl_drm_interface'
> make[3]: *** [compositor]
On 03/12/2011 02:20 PM, Bill Spitzak wrote:
> On 03/12/2011 04:28 AM, Marty Jack wrote:
>> I have never encountered a system where it was believed to be desirable to
>> allow something to be removed twice. It is important to keep data
>> structures clean. If anything you
On 03/12/2011 02:20 PM, Bill Spitzak wrote:
> On 03/12/2011 04:28 AM, Marty Jack wrote:
>> I have never encountered a system where it was believed to be desirable to
>> allow something to be removed twice. It is important to keep data
>> structures clean. If anything you
ent is
> already in a list or not. So if there is a way to know that, why not make a
> check inside wl_list_remove, just to make sure.
>
> I'll fix it the way you want it to be :)
>
> Regards,
> Iskren
>
> On Sat, Mar 12, 2011 at 1:07 PM, Marty Jack <mailto:m
On 03/11/2011 07:32 PM, Iskren Chernev wrote:
> Hello,
>
> I found a bug and fixed it with the patch :)
>
> *to reproduce:*
> run compositor on top of x11
>
> repeat
>run flower
>drag & drop it a little
>move the pointer in and out of the compositor/flower
>Ctrl+C the flower cl
On 03/06/2011 12:41 PM, nerdopolis wrote:
> Hi.
>
>
> I just want to bring this up for early consideration:
>
>
> It seems that many things in Wayland will be determined by they type of
> compositor server you are running, such as if you want to have a tiling
> window manager in Wayland, or
Yesterday there were some checkins to the Wayland support in Mesa that
duplicate symbols of the general form wl_drm_* defined in
/usr/include/wayland-client-protocol.h and wayland-server-protocol.h. This
causes the Mesa build to fail.
There is not yet a compensating checkin to Wayland that res
On 02/26/2011 08:36 AM, José Expósito wrote:
>> You will find Compiz and Openbox people actively participating here, so I
>> would expect your favorite
>> variety of window placement and decoration to appear in due course.
>
> Excellent, but how about migrating my owns programs? API/Documentati
On 02/26/2011 08:14 AM, microcai wrote:
> 2011/2/26 José Expósito :
>> Hi! thanks for the answers... but now I have more questions that at
>> begining hahaha
>>
>>> 1 - Wayland support window management?
>>> Wayland is a compositor+window manager+display server AIO
>>
>> If Wayland is the window
On 02/26/2011 04:50 AM, 李海梅 wrote:
> Hi, guys
>
> I tried to test QT on wayland, and after I compile the QT-wayland with the
> latest version of codes, I failed to run the examples of QT examples in
> Wayland terminal,
>
> the system gives the following prompt:
>
> failed to find _glapi_g
On 02/23/2011 07:26 AM, Andreas Hartmetz wrote:
> On Wednesday 23 February 2011 00:31:56 Marty Jack wrote:
>> On 02/22/2011 01:16 PM, Andreas Hartmetz wrote:
>>> Hello,
>>>
>>> I've started a Wayland implementation currently called "area", writt
On 02/22/2011 01:16 PM, Andreas Hartmetz wrote:
> Hello,
>
> I've started a Wayland implementation currently called "area", written in
> C++ and with the main goal to work on all hardware that currently works
> on Linux in some way (Framebuffer or X11).
> I've started with the network code and n
On 02/19/2011 12:59 AM, microcai wrote:
> I used to think wayland is better.
> But now, I don't.
>
>
> What is Wayland ?
>
> Let me tell you:
>
> Final Wayland = X11 that rip out everything but GLX.
> Current wayland still missing Input framework like XIM. And batch of
> other stuffs. Adding
On 02/19/2011 12:59 AM, microcai wrote:
> I used to think wayland is better.
> But now, I don't.
>
>
> What is Wayland ?
>
> Let me tell you:
>
> Final Wayland = X11 that rip out everything but GLX.
> Current wayland still missing Input framework like XIM. And batch of
> other stuffs. Adding
For your purposes, it is easier to think of Wayland as playing the role of the
window manager. The style of the cursor in each application would be
controlled by the drawing toolkit, be it GTK or Qt or some other. These
toolkits have ways for the application to set whatever cursor they like, a
On 02/16/2011 04:46 PM, Kevin Porter wrote:
> Hello,
>
> I am attending in an open source software class where we learn how to
> participate in an open source community. Part of the class is to find a
> project that we are interested in and work on some entry level
> bugs/documentation problem
On 02/09/2011 07:08 PM, Alex Deucher wrote:
> On Wed, Feb 9, 2011 at 7:01 PM, Marty Jack wrote:
>> I have a little patch that allocates the CRTCs to avoid the multiple monitor
>> black screen. If you don't want it right now that's fine too.
>>
>> I don&#
I have a little patch that allocates the CRTCs to avoid the multiple monitor
black screen. If you don't want it right now that's fine too.
I don't know what Kristian's ultimate vision of this is. Do we allow windows
to move like they do now on a virtual desktop where you can slide one to a
Ri
I tripped across a little something that others might also.
http://www.mesa3d.org/egl.html
Referring to "Use EGL", EGL_PLATFORM, the --with-egl-platforms is order
dependent, so you must
specify wayland before drm as is shown in the configure or have
EGL_PLATFORM=wayland at runtime to run a clien
On 02/07/2011 08:18 AM, Kristian Høgsberg wrote:
> On Mon, Feb 7, 2011 at 4:39 AM, Marty Jack wrote:
>> With this patch, crashed compositors won't prevent a new one from starting,
>> and unprivileged clients can connect.
>
> Hi Marty,
>
> The compositor is
With this patch, crashed compositors won't prevent a new one from starting, and
unprivileged clients can connect.
diff --git a/wayland/wayland-server.c b/wayland/wayland-server.c
index dece0d1..6b5f503 100644
--- a/wayland/wayland-server.c
+++ b/wayland/wayland-server.c
@@ -33,6 +33,7 @@
#includ
Okay, small digression to explain the problem and then we're back to doing a
window system.
Consider:
>>> struct drm_version {
>>>int version_major;/**< Major version */
>>>int version_minor;/**< Minor version */
>>>int version_patchlevel; /**< Patch leve
On 02/06/2011 04:28 PM, Dave Airlie wrote:
> On Mon, Feb 7, 2011 at 6:48 AM, Marty Jack wrote:
>> Well, I have over 40 years experience, a lot of it on Unix and more recently
>> Linux and a lot of it doing compilers, so data typing is second nature.
>>
>> But, I&
Well, I have over 40 years experience, a lot of it on Unix and more recently
Linux and a lot of it doing compilers, so data typing is second nature.
But, I'm getting a little older, I could be mistaken and I'm always happy to
learn something new. Maybe sometime when you have a moment you would
I spent the weekend learning my way around and debugging the DRM compositor
running on bare hardware. Successful, but some issues and observations.
As is documented, you need to make sure you have your video and input devices
labelled with the udev property WAYLAND_SEAT="1". I have a program t
On 02/05/2011 05:39 AM, Carl-Philip Haensch wrote:
> Hi,
>
> I noticed that mouseover texts for linux are the same for each app I use. So
> it seems to be part of the compositor/of X11 to show Hover-Texts.
>
> In wayland protocol, i did not find a request to show a hover text or
> something.
Applications
XRandR replacement
I recommend supporting only what is a Virtual desktop under X
Have all video cards and their outputs mapped onto that space,
dispense with Screens, Xinerama, Zaphod, other means of doing this that have
been used
Design choice recommendations
Move to a single character set (UTF-8)
Move to a single coordinate space for multiple video cards, multiple
outputs on same video card
I think EGLDisplay should be what X would call a Virtual screen
and that is large enough to combine
X Protocol standards
Base protocol
Assuming window creation/deletion
Assuming something for key, button, motion, focus change, and
enter/leave events
Assuming something for cursors, something for grabs
Something for assigning
Packaging issues
User-side fonts: right now, upstream is x.org for many of them
What of bdftopcf, mkfontdir, mkfontscale
What of bitmap fonts
User-side cursors:
What of xcursorgen, libXcursor, the on-disk format
Packaging issues
User-side fonts: right now, upstream is x.org for many of them
What of bdftopcf, mkfontdir, mkfontscale
What of bitmap fonts
User-side cursors:
What of xcursorgen, libXcursor, the on-disk format
Programmer viewpoint
Are we having background pixmaps and borders? Should be always client
drawn, yes?
Non-rectangular windows and an equivalent for the Shape extension
Tracing, debugging, performance hooks libXtst, xev, xscope, x11perf
Selections as distributed
User viewpoint
Device initialization
Something equivalent to xorg.conf and xorg.conf.d for devices
that need some sort of initialization quirk or blacklisting
(Comes up constantly on xorg mailing list - must
address)
Setup applications and A
A draft checklist for areas that I think would be required to get completely
off of X onto Wayland, if that's a goal.
I have not done an exhaustive analysis to see if things are implemented yet.
Nor have I attempted a design of the mechanisms. This is more of a checklist /
requirements docume
On 01/24/2011 02:22 PM, Chase Douglas wrote:
> On 01/24/2011 01:57 PM, Jesse Barnes wrote:
>> On Sun, 23 Jan 2011 21:03:58 -0500
>> Chase Douglas wrote:
>>> First I'd like to address what I think we can learn from X. X11 has a
>>> core protocol and an XInput extension with two major versions. To
On 01/23/2011 09:03 PM, Chase Douglas wrote:
> Hi all,
>
> I haven't been involved in wayland development at all yet :), but I have
> been working on XInput 2.1 multitouch additions and gesture work in
> Ubuntu. I have a few thoughts on how a new input system for wayland
> might work.
>
> To go
You have it right.
When a client does a connect on a socket that another process is listening to
(the listen is at line 692), this makes the other end get a "readable" on its
end of the socket. You then do an accept, which gives you a new fd for your
end of the connection. You then have a bid
The major problem with PropertyNotify events, or with having generalized
properties of any kind, is that they are too much like polled interrupts rather
than vectored interrupts. You get the event, but you then have to poll to see
which thing changed.
Also, the protocol design seems to be more
This is (a) really the wrong place to complain about the X Window System and
(b) this mechanism has all been in place and stable and heavily used for many
years and is not likely to change in any significant way.
Concerning what is going to be done in Wayland, we are not to the point of
designi
I think he said he hadn't implemented that yet and it would come in the next
patchset. It's an OSC 0 ; window-title ST sequence that xterm supports to set
the window title.
On 01/10/2011 11:03 AM, Tiago Vignatti wrote:
> FYI, I'm still getting the following message and the "0;":
> "Unknown esca
On 01/07/2011 02:47 PM, Callum Lowcay wrote:
> Includes the 3 vt100 character sets. Some of the graphic symbols don't
> display because they are not included in the default font. Apparantly
> the cairo toy font API doesn't do font substitution.
>
> Signed-off-by: Callum Lowcay
> ---
> clients/
There is a part of the keyboard description called the Compatibility Map. This
is supposed to be for clients that predate Xkb, and gives rules for how to map
Xkb modifier events onto pre-Xkb events.
It's also the case that is a huge part of the Xkb description, almost the size
of the Geometry
I hope that last comment didn't come across as snippy. It merely meant to
point out that, for any piece of software, there are folks who use it and folks
who don't. The idea that there should be more than one way to do everything
goes all the way back to when the students at Berkeley thought t
On 01/07/2011 06:18 PM, Behdad Esfahbod wrote:
> On 01/07/11 09:57, Kristian Høgsberg wrote:
>> However, as Behdad says, a more future proof and fully featured
>> terminal would probably use vte (or the kde terminal emulator), but
>> that doesn't have to mean that the wayland terminal can't be a f
This is not unlike how, on Macintosh, you normally run without an X server
unless you want to run an X client, in which case you start one and the X
server interoperates with the Macintosh graphics. Or how on a virtualized
guest the X server has special drivers to interoperate with the virtuali
I found the following by doing this experiment:
martyj:~$ find /usr/include -exec grep -H I915_EXEC_ {} \;
/usr/include/libdrm/i915_drm.h:#define I915_EXEC_RING_MASK (7<<0)
/usr/include/libdrm/i915_drm.h:#define I915_EXEC_DEFAULT(0<<0)
/usr/include/libdrm/i915_drm.h:#d
"designed and implemented a lightweight window server for a major series of
products" eh? You're a bit too modest about that particular accomplishment ...
Been there about deliberately take a couple of years off since retiring as a
way to rest and recharge.
That was a nice writeup by Stefanos
On 12/10/2010 10:38 AM, Sam Spilsbury wrote:
> On Fri, Dec 10, 2010 at 10:21 PM, Marty Jack wrote:
>> There have been hints that client side input processing should be the norm
>> in Wayland. This makes a lot of sense if client side drawing is the norm.
>>
>> This i
There have been hints that client side input processing should be the norm in
Wayland. This makes a lot of sense if client side drawing is the norm.
This is a Big Decision with quite a lot of implications and it needs some
design thought.
Let's take a look at what input processing happens now
What month do we think it will be when we have a stable GTK that runs over
Wayland. Probably also need a Qt in order to cut over completely. For example
I have an HP printer and the printer management application is written in
Python over PyQt over Qt and I would lose the ability to see how mu
On 12/09/2010 03:00 PM, wayland-devel-requ...@lists.freedesktop.org wrote:
> Send wayland-devel mailing list submissions to
> wayland-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
:06 -0500
>> skrev Marty Jack :
>>> Also, I don't yet fully buy
>>> into the part about no client controlled window placement. We need
>>> some way for docks to position themselves appropriately.
>>
>> Client controlled window placement is importa
59 matches
Mail list logo
