On Tue, Oct 13, 2015 at 04:18:19PM -0700, Bryce Harrington wrote:
> On Fri, Oct 09, 2015 at 10:07:48PM +0200, David FORT wrote:
> > Server-side we need to know the versions for destructor requests.
> >
> > Signed-off-by: David FORT
>
> Reviewed-by: Bryce Harrington
>
> > ---
> > src/scanner.c
On Tue, Oct 13, 2015 at 06:37:43PM -0500, Derek Foreman wrote:
> On 13/10/15 06:32 PM, Bryce Harrington wrote:
> > On Fri, Oct 09, 2015 at 11:28:42AM -0500, Derek Foreman wrote:
> >> Tizen's been carrying around a patch for this, but it only works for full
> >> screen unrotated compositors. I've t
On 13/10/15 06:32 PM, Bryce Harrington wrote:
> On Fri, Oct 09, 2015 at 11:28:42AM -0500, Derek Foreman wrote:
>> Tizen's been carrying around a patch for this, but it only works for full
>> screen unrotated compositors. I've tried to re-write it in a more general
>> way.
>>
>> Also, a little grat
On Tue, Oct 13, 2015 at 04:32:39PM -0700, Bryce Harrington wrote:
> On Fri, Oct 09, 2015 at 11:28:42AM -0500, Derek Foreman wrote:
> > Tizen's been carrying around a patch for this, but it only works for full
> > screen unrotated compositors. I've tried to re-write it in a more general
> > way.
>
On Fri, Oct 09, 2015 at 11:28:42AM -0500, Derek Foreman wrote:
> Tizen's been carrying around a patch for this, but it only works for full
> screen unrotated compositors. I've tried to re-write it in a more general
> way.
>
> Also, a little gratuitous clean-up in here too.
>
> Derek Foreman (4):
On Fri, Oct 09, 2015 at 11:28:46AM -0500, Derek Foreman wrote:
> Adds support for touch devices to the wayland backend.
>
> Signed-off-by: Derek Foreman
Reviewed-by: Bryce Harrington
One bikeshed below...
> ---
> src/compositor-wayland.c | 149
> +
On Fri, Oct 09, 2015 at 05:44:00PM +0100, Daniel Stone wrote:
> On 9 October 2015 at 17:28, Derek Foreman wrote:
> > I'll be using this in a follow up patch that adds touch input to weston's
> > wayland backend.
> >
> > Signed-off-by: Derek Foreman
>
> Reviewed-by: Daniel Stone
LGTM too.
Revi
On Fri, Oct 09, 2015 at 10:07:48PM +0200, David FORT wrote:
> Server-side we need to know the versions for destructor requests.
>
> Signed-off-by: David FORT
Reviewed-by: Bryce Harrington
> ---
> src/scanner.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/scanner.c b/src/scann
On Tue, Oct 13, 2015 at 08:27:58PM +0100, Auke Booij wrote:
> On 13 October 2015 at 16:19, Solerman Kaplon wrote:
> > Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
> >>
> >> In C++ the order doesn't matter either, since each entry has a defined
> >> value. I wonder why this is different in Java?
On 08/10/15 03:00 PM, Daniel Stone wrote:
> Hi,
>
> On 8 October 2015 at 08:27, Jonas Ådahl wrote:
>> On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote:
>>> There are cases in weston where it would be quite nice to have a
>>> sentinel value to use instead of having to have a bool for
On 13 October 2015 at 16:19, Solerman Kaplon wrote:
> Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
>>
>> In C++ the order doesn't matter either, since each entry has a defined
>> value. I wonder why this is different in Java?
>
>
> Java Enums doesn't have "value". It just a class instance. But
On 10/13/2015 10:28 AM, Jasper St. Pierre wrote:
In one case, an invalid serial dictates that the window should have it's
focus attempts prevented. In the no-serial case, focus world be stolen.
Yes, I have heard that. However I still find it hard to believe any
compositor is going to be implem
In one case, an invalid serial dictates that the window should have it's
focus attempts prevented. In the no-serial case, focus world be stolen.
On Tue, Oct 13, 2015, 10:25 AM Bill Spitzak wrote:
> On 10/13/2015 09:53 AM, Jasper St. Pierre wrote:
> > The goal of focus-stealing prevention isn't t
On 10/13/2015 09:53 AM, Jasper St. Pierre wrote:
The goal of focus-stealing prevention isn't to prevent hostile clients
from stealing the focus. It's to allow friendly clients to upgrade the
experience if they can track the originating event that originally
opened a window. For instance, if I lau
On 10/13/2015 08:18 AM, Erik De Rijcke wrote:
Because Java is not C/C++. In Java, enum values are unique by instance
alone. It does not have user 'defined' value(s) that make it unique. It
*can* have user defined properties (like any object) in addition to
implicit compiler generated enum type
The goal of focus-stealing prevention isn't to prevent hostile clients
from stealing the focus. It's to allow friendly clients to upgrade the
experience if they can track the originating event that originally
opened a window. For instance, if I launch GIMP but then go back to
typing in a terminal,
On 10/08/2015 01:00 PM, Daniel Stone wrote:
Hi,
On 8 October 2015 at 08:27, Jonas Ådahl wrote:
On Mon, Oct 05, 2015 at 12:04:49PM -0500, Derek Foreman wrote:
There are cases in weston where it would be quite nice to have a
sentinel value to use instead of having to have a bool for "this seria
On 10/08/2015 10:15 AM, Derek Foreman wrote:
On 07/10/15 07:41 PM, Jonas Ådahl wrote:
I think it would be nice to land this in the same release cycle (ie:
this one) as pointer confinement, because I think the two features
really go hand in hand.
Indeed. Relative pointer events are quite usel
On Tue, Oct 13, 2015 at 5:18 PM, Erik De Rijcke wrote:
>
>
> On Tue, Oct 13, 2015 at 4:35 PM, Nils Chr. Brause
> wrote:
>>
>> Hi,
>>
>> On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen
>> wrote:
>> > On Mon, 12 Oct 2015 10:41:22 +0200
>> > Erik De Rijcke wrote:
>> >
>> >> Adding enum members is
Agreed. It should be possible to pop up windows from the keyboard.
On Tue, Oct 13, 2015 at 8:41 AM, Bill Spitzak wrote:
> On 10/06/2015 02:48 PM, Ben Hummon wrote:
>>
>> Weston does not allow popup menus initiated by keyboard. Remove the
>> broken keyboard shorcut for a popup from the stacking de
On 10/06/2015 02:48 PM, Ben Hummon wrote:
Weston does not allow popup menus initiated by keyboard. Remove the
broken keyboard shorcut for a popup from the stacking demo.
Signed-off-by: Ben Hummon
---
clients/stacking.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Em 13-10-2015 11:35, Nils Chr. Brause escreveu:
In C++ the order doesn't matter either, since each entry has a defined value.
I wonder why this is different in Java?
Java Enums doesn't have "value". It just a class instance. But since it's a
class one can add regular fields to it, like this (w
On Tue, Oct 13, 2015 at 4:35 PM, Nils Chr. Brause
wrote:
> Hi,
>
> On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen
> wrote:
> > On Mon, 12 Oct 2015 10:41:22 +0200
> > Erik De Rijcke wrote:
> >
> >> Adding enum members is backward compatible for Java. If you compile
> against
> >> an enum with
Hi,
On Mon, Oct 12, 2015 at 11:08 AM, Pekka Paalanen wrote:
> On Mon, 12 Oct 2015 10:41:22 +0200
> Erik De Rijcke wrote:
>
>> Adding enum members is backward compatible for Java. If you compile against
>> an enum with 2 members, and later on a new member is added, you can simply
>> use the new v
These are the debug traces of the application:
DM-37x# ./weston-fullscreen -w 800 -h 600
[346.819] -> wl_display@1.get_registry(new id wl_registry@2)
[3470006.899] -> wl_disp...@1.sync(new id wl_callback@3)
[3470013.399] wl_display@1.delete_id(3)
[3470014.620] wl_registry@2.global(1, "wl_com
This is the backtrace but not much information is provided:
Starting program: /usr/var/lib/weston-fullscreen
[Thread debugging using libthread_db enabled]
[New Thread 0x40105000 (LWP 325)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40105000 (LWP 325)]
0x0008 i
Pekka,
Thanks for your information. I've compiled simple clients and I've
executed fullscreen clients:
DM-37x# ./weston-fullscreen
Segmentation fault
And finishes with a segmentation fault. I'll rerun with debug
information to provide more information.
2015-10-13 14:37 GMT+02:00 Pekka Paalanen
On Tue, 13 Oct 2015 14:26:21 +0200
Joaquim Duran wrote:
> Hello,
>
> We could execute the Weston compositor (using fbdev backend) in a
> terminal, we could execute the weston-info client and it prints
> information, however when we execute the weston-terminal client, it
> couldn't open a window
Hello,
We could execute the Weston compositor (using fbdev backend) in a
terminal, we could execute the weston-info client and it prints
information, however when we execute the weston-terminal client, it
couldn't open a window on the compositor.
We start the Weston compositor in a terminal:
mkd
Hello,
When configuring the Weston project, it is possible to disable (don't
include) the library libxkbcommon. To compile Weston successfully,
even if the option --disable-xkbcommon is specified, the library must
be installed because the file src/compositor.h requires it.
Some code of file src/c
Creating rule with following line and then running the following two
commands made touch working.
SUBSYSTEM=="input", ENV{ID_INPUT}="1", ENV{ID_INPUT_TOUCHSCREEN}="1"
/lib/systemd/systemd-udevd --daemon
udevadm test /devices/virtual/input/input0/event0
udevadm info /dev/input/event0
Thanks for y
Version weston 1.9.0
Configuration:
./autogen.sh \
--disable-devdocs \
--disable-dbus \
--disable-xwayland \
--disable-xwayland-test \
--disable-x11-compositor \
--disable-drm-compositor \
--disable-wayland-compositor \
--disable-headless-compositor \
--disable
On Tue, 13 Oct 2015 12:19:47 +0200
Joaquim Duran wrote:
> Hello,
>
> Last Friday, we executed Weston for first time. We also view the black
> screen in full screen shell. Weston breaks when desktop shell is used.
Hi Joaquim,
this email thread is about fullscreen windows on desktop shell, not
a
Hello,
Last Friday, we executed Weston for first time. We also view the black
screen in full screen shell. Weston breaks when desktop shell is used.
Joaquim Duran
2015-10-09 9:29 GMT+02:00 Pekka Paalanen :
> On Fri, 9 Oct 2015 10:04:49 +0300
> Giulio Camuffo wrote:
>
>> You get a black surface
34 matches
Mail list logo
