From: Pekka Paalanen
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/188
Signed-off-by: Pekka Paalanen
---
xserver.html | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xserver.html b/xserver.html
index 174b2ab..000f743 100644
--- a/xserver.html
+++ b/xserver.html
stribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/
FWIW, Weston already has a small plugin to use colord. The only thing
it does to apply anything is to set the simplest form of the
weston[30514]: segfault at 55813301b3c0 ip 55813301b3c0 sp
7ffe1994ac58 error 15
[ 2752.917756] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 04 00 00 00 00 00
00 b9 46 33 81 55 00 00 c8 0b 02 33 81 55 00 00 00 39 01 33
Hi Harish,
On Wed, 23 Jan 2019 at 09:35, Pekka Paalanen wrote:
> On Wed, 23 Jan 2019 11:32:34 +0530 Harish Krupo
> wrote:
> > Proposal 1:
> > * Each of the shaders (gamma/degamma/main/tone mapping) would be
> > independent strings.
> > * When the view needs to be rendered, renderer will
Hi Ankit,
On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
wrote:
>
> Hi Ole,
>
> I was going through the protocol you had proposed, and have some silly
> questions, please pardon my ignorance.
>
> From where can the client-applications get the ICC profile files? Does
> the client
is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content/buffers are composed in REC2020 colorspace
top.org/archives/wayland-devel/2014-March/013951.ht
> > ml
> >
> > Best regards,
> > Ole
> >
> > Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank:
> >> Hello All,
> >>
> >> This mail is to propose a design for
, Shashank:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content
On Wed, 30 Jan 2019 09:47:39 +1000
Peter Hutterer wrote:
> On Tue, Jan 29, 2019 at 03:36:41PM +0200, Pekka Paalanen wrote:
> > On Tue, 29 Jan 2019 16:57:34 +1000
> > Peter Hutterer wrote:
> >
> > > The new API returns scroll wheels as fractions of 120.
> > >
> > > Signed-off-by: Peter
for a single API call here. Do you have a preference?
> > +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> > +
> > dep_libm = cc.find_library('m')
> > dep_libdl = cc.find_library('dl')
> > dep_libdrm = dependency('libdrm', version: '>= 2.4.68
put_event_pointer_get_axis_value regardless of the source. Is the
> multiply-by-10 workaround supposed to be implemented in all
> compositors?
it's a backwards-compatibility thing Weston has (and mutter too). The
wayland protocol says that pointer axis x/y are the same dimension as
pointer
On Tuesday, January 29, 2019 7:57 AM, Peter Hutterer
wrote:
> switch (source) {
> case LIBINPUT_POINTER_AXIS_SOURCE_WHEEL:
> +#if HAVE_LIBINPUT_AXIS_V120
> + value = 10 * libinput_event_pointer_get_axis_value_v120(
> +
20)
> +
> dep_libm = cc.find_library('m')
> dep_libdl = cc.find_library('dl')
> dep_libdrm = dependency('libdrm', version: '>= 2.4.68')
Fine by me, but I can't claim to have actually verified the correctness
of the semantics. A W
the compositor works in a very specific way, that may
not match the hardware it has to work with, maybe avoiding the full
potential of the hardware
- the profile is for an output as a whole, which means that if you
installed a profile that includes effects from pixel fo
The new API returns scroll wheels as fractions of 120.
Signed-off-by: Peter Hutterer
---
Turns out it's not the most complicated patch...
This is an RFC only because libinput hasn't been released yet, and it's
waiting on the kernel release anyway. Given the expected delay, I hope
autotools is
e profile. More complex from a Wayland point of view
appears to be getting control of the test window output, location
& size (although I get the impression some of this is doable using
xdg protocols ?)
> As an example of orthogonality, I would like to point to the new
> touchscreen calibration too
On Thu, 24 Jan 2019 11:47:30 +0200
Pekka Paalanen wrote:
> On Wed, 23 Jan 2019 18:43:52 +
> "Singh, Satyeshwar" wrote:
>
> > Imagine a benchmark case where the client renders for example 800
> > frames and attaches their buffer ids to a surface, the compositor
> > uses the last one that
On Wed, 23 Jan 2019 18:43:52 +
"Singh, Satyeshwar" wrote:
> Hey guys,
> As you know, Weston doesn't wait for client buffers to finish
> rendering. That is typically left as an exercise for the kernel mode
> graphics driver. I am wondering if anyone knows why this poli
On Wed, 23 Jan 2019 19:28:11 +
"Ucan, Emre (ADITG/ESB)" wrote:
> Hello Satyeshwar,
>
> nice to hear from you again (:
>
> short answer to your question: there is already implementation which is doing
> what you are asking:
> https://gitlab.freedesktop.org/w
and
> see if anyone complains?
>
TBH, the user base is likely not as high as it was in 2012. It's prime focus
was to allow users to test anything Wayland live. So I don't think that would
be a good way to tell, since now there are other more popular ways people have
been using it now.
On Tue, 22 Jan 2019 10:17:32 +0200
Pekka Paalanen wrote:
keep it around for some more, but the simple fact that some hardware
exists that does not have a working DRM driver is not enough
Fbdev worked out of the box on my Bay Trail system, but DRM kept
freezing where only SysRq helped. It
Hello Satyeshwar,
nice to hear from you again (:
short answer to your question: there is already implementation which is doing
what you are asking:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/32
Best regards
Emre Ucan
Engineering Software Base (ADITG/ESB)
Tel. +49 5121 49
Hey guys,
As you know, Weston doesn't wait for client buffers to finish rendering. That
is typically left as an exercise for the kernel mode graphics driver. I am
wondering if anyone knows why this policy decision was made? More importantly,
is there any harm (or any side effect) that I am
On Tue, 2019-01-22 at 22:46 -0500, nerdopolis wrote:
> Well, TBH, It's just my quazi-distribution Live CD that I still maintain...
> It falls back to the Framebuffer on systems (or seats) that don't have
> Kernel Mode Setting. The number of users now probably is low...
I think the biggest class
single "megashader" vs. multiple
> specific shaders can be left out for now. Unless someone has solid
> knowledge about what would be best already?
>
> Of course, we should stick to GL ES 2.0 capabilities if possible, but
> we could also consider requiring GL ES 3.0 if that woul
st already?
Of course, we should stick to GL ES 2.0 capabilities if possible, but
we could also consider requiring GL ES 3.0 if that would seem too
useful to ignore.
Thanks,
pq
>
> [1]
> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.ht
low...
Right. Would you be able to do a test? Disable fbdev on your distro and
see if anyone complains?
In fact, would be nice if all distributions did that test. I'm not in
that much hurry to delete the backend yet.
> VT switching works great. It works without weston-launch, and I
and do suggest if there is a better
one.
Thank you
Regards
Harish Krupo
[1]
https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html
[2] https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257
___
wayland-dev
ll. Maybe not for
> > > Virtual
> > > Box anymore, since there is now a driver for it in Mainline (I haven't
> > > tested
> > > it personally though) ...Currently the Framebuffer backend is the only
> > > way to
> > > get Weston working on some obscu
are required elsewhere. Any strong opinions either
> > > way?
>
> > I feel like the fbdev backend is a good fallback still. Maybe not for
> > Virtual
> > Box anymore, since there is now a driver for it in Mainline (I haven't
> > tested
> > it personally though
>>> On Thu, 10 Jan 2019 20:32:18 +0530
> >>> "Sharma, Shashank" wrote:
> >>>
> >>>> Hello All,
> >>>>
> >>>> This mail is to propose a design for enabling HDR support in
> >>>> Wayland/Weston st
manageable chunks anyway.
Surely the color characterisation of a monitor is not specific to a
window system? While we still don't have a good solution to
measurements in Wayland, people can measure their monitors on Xorg, or
even Windows, I hope. Or even better: using a measuring tool
Am 18.01.19 um 09:08 schrieb Graeme Gill:> Maybe rendering specifically
for one output is sufficient
> as long as the secondary displays (however that is determined!) look
> OK with a fallback conversion by the compositor.
Currently the first or main monitor is the primary rendering target. As
Sharma, Shashank wrote:
Hi,
> Yes, this is very accurate. We are planning to add a protocol extension,
> which will allow
> a client to pass the buffers colorspace information to the compositor. And
> compositor
> already has HW's color capabilities (drm properties per plane and CRTC), and
>
Adam Jackson wrote:
Hi,
> This isn't necessarily true. The server is free to just draw a black
> rectangle (or nothing) instead if the image doesn't match the target
> colorspace. If you want to handle the case of cloned outputs or
> crossing output borders, let the client attach one image per
Pekka Paalanen wrote:
Hi,
> If a wl_surface straddles multiple outputs simultaneously, then
> wl_surface.enter/leave events indicate the surface being on all those
> outputs at the same time. The client is expected to take all the
> entered outputs into consideration when it chooses how to
design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
*snip*
I understand your aim is to leverage display hardware capabilities to
the fullest, but we must also consider hardware that lacks some or all
of th
; colorspace.
Hi Adam,
in my opinion it is not acceptable in a Wayland compositor.
Wayland protocol does not say anything about the final visual, so
showing a corrupted window (black, invisible, whatever) is not a
protocol violation per se, but I still think it would be a buggy
compositor if I can o
On Tue, 15 Jan 2019 13:19:00 +0100
Niels Ole Salscheider wrote:
> Am Dienstag, 15. Januar 2019, 10:30:14 CET schrieb Pekka Paalanen:
> > Yes and no. Yes, we do and should let clients know what kind of outputs
> > their contents will be shown on. However, we will in any case need the
> >
On Wed, 16 Jan 2019 09:25:06 +0530
"Sharma, Shashank" wrote:
> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:
> > On Thu, 10 Jan 2019 20:32:18 +0530
> > "Sharma, Shashank" wrote:
> >
> >> Hello All,
> >>
> >> This mail is to pr
Hi Arnaud,
Thank you for the comments, please find mine inline.
Arnaud Vrac writes:
> On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank
> wrote:
>>
>> > The proposal is missing many important bits like negotiation of the
>> > supported output features with the client, double buffering the new
Hello All,
> >>
> >> This mail is to propose a design for enabling HDR support in
> >> Wayland/Weston stack, using display engine capabilities, and get more
> >> feedback and input from community.
> >> Here are few points (you might already
Hello Arnaud
Thanks for your comments, mine inline.
Regards
Shashank
On 1/17/2019 6:38 AM, Arnaud Vrac wrote:
On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
wrote:
Hello All,
This mail is to propose a design for enabling HDR support in Wayland/Weston
stack, using display engine
On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
wrote:
>
> Hello All,
>
> This mail is to propose a design for enabling HDR support in Wayland/Weston
> stack, using display engine capabilities, and get more feedback and input
> from community.
> Here are few points (y
the most important thing for us, as a team,
would be to break this implementation into small measurable steps which
slowly targets respective areas of Weston development, keeping the end
goal alive.
- HDR content/buffers are composed in REC2020 colorspace, with bit depth
10/12/16 BPC.
Some
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content/buffers ar
On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> On Tue, 15 Jan 2019 13:47:07 +1100
> Graeme Gill wrote:
>
> > If done in the composer, it would need to render the graphic elements to
> > the output DPI / convert the source colorspace to the output colorspace.
> > But the composer
ity modes might be highly desirable
> > (I have some thoughts on that), but in any case, it would also help the
> > quality of such backward compatibility _and_ compositing (i.e. linear
> > light compositing option), if Wayland at least had access to the output
> > color
; compositing option), if Wayland at least had access to the output color
> profiles. So there is a lot of advantage in Wayland providing the
> registry/API of output color profiles both for itself, and clients.
That backward compatibility / fallback is an integral part of the image
transfor
Pekka Paalanen wrote:
Hi Pekka,
thanks for your response.
>> As far as I was informed, Wayland
>> is architected in such a way that this is not possible, since clients
>> have no knowledge of which display the pixels they send will end up on.
>
> Nothing has changed there.
I've been
From: Pekka Paalanen
The Xwayland setting syntax was changed in
https://gitlab.freedesktop.org/wayland/weston/commit/6d3887baec12c3a2b833301907546fba8c1fb26d
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/186
Signed-off-by: Pekka Paalanen
---
xserver.html | 4 ++--
1 file
On Fri, 11 Jan 2019 18:25:01 +1100
Graeme Gill wrote:
> Sharma, Shashank wrote:
>
> Hi,
>
> While I'm sure you could hard code various color space assumptions into
> such an implementation (and perhaps this is a pretty reasonable way
> of doing a proof of concept), it's not a good long term
On Thu, 10 Jan 2019 20:32:18 +0530
"Sharma, Shashank" wrote:
> Hello All,
>
> This mail is to propose a design for enabling HDR support in
> Wayland/Weston stack, using display engine capabilities, and get more
> feedback and input from community.
> Here are few po
--- a/building.html
+++ b/building.html
@@ -179,20 +179,37 @@ libinput docs for instructions on how to build it.
available in the weston repo and comes with a few demo applications.
+Weston is built with https://mesonbuild.com/;>Meson. The last
+Weston release with autotools build system is proba
From: Pekka Paalanen
The Wayland and Weston instructions are different.
Signed-off-by: Pekka Paalanen
---
index.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/index.html b/index.html
index ab6259f..320cd9a 100644
--- a/index.html
+++ b/index.html
@@ -54,7 +54,8
Sharma, Shashank wrote:
Hi,
While I'm sure you could hard code various color space assumptions into
such an implementation (and perhaps this is a pretty reasonable way
of doing a proof of concept), it's not a good long term solution,
and could end up being something of a millstone. What's
,
I will come back with my feedback for this stack, soon.
- Shashank
Best regards,
Ole
Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get
This mail is to propose a design for enabling HDR support in
> Wayland/Weston stack, using display engine capabilities, and get more
> feedback and input from community.
> Here are few points (you might already know these), about HDR
> framebuffers, videos and displays:
> - HDR content/buffers
If the block diagram is not aligned due to mail client, please refer to
the attached .txt file. Hope thats slightly better :).
Regards
Shashank
On 1/10/2019 8:32 PM, Sharma, Shashank wrote:
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using
Hello All,
This mail is to propose a design for enabling HDR support in
Wayland/Weston stack, using display engine capabilities, and get more
feedback and input from community.
Here are few points (you might already know these), about HDR
framebuffers, videos and displays:
- HDR content
runs and so. It's generally
what xvfb-run provides - a headless X11 server which launches a single
command and quit when the command finishes.
Is that possible with Weston and any of its backend? I haven't found any
reference how to launch firefox inside weston-headles backend
automatically so far
this hopefully fixes the issue with pangocairo and demonstrates
> what kind of error messages I envision to have for roughly
> everything:
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/72
>
> Could you give it a try?
Hi Jan,
FYI, this was just merged
nerally
> what xvfb-run provides - a headless X11 server which launches a single
> command and quit when the command finishes.
>
> Is that possible with Weston and any of its backend? I haven't found any
> reference how to launch firefox inside weston-headles backend
> a
command and quit when the command finishes.
Is that possible with Weston and any of its backend? I haven't found any
reference how to launch firefox inside weston-headles backend
automatically so far.
Thanks,
ma.
___
wayland-devel mailing list
wayland
t's the point where I'd get frustrated.
> (because shared/, unlike clients/, seems to have it marked as optional
> already AFAICT)
Hi Jan,
this hopefully fixes the issue with pangocairo and demonstrates
what kind of error messages I envision to have for roughly
everything:
https://gitlab.freedesktop.
On Fri, 14 Dec 2018 15:16:29 +0100 (CET)
Jan Engelhardt wrote:
> On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote:
> >
> >here is an early Christmas / NewYear present / bomb (take your pick). I just
> >merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/
On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote:
>
>here is an early Christmas / NewYear present / bomb (take your pick). I just
>merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/8 which
>adds Meson build system to Weston.
>
>Most build opti
Hi,
here is an early Christmas / NewYear present / bomb (take your
pick). I just merged
https://gitlab.freedesktop.org/wayland/weston/merge_requests/8
which adds Meson build system to Weston.
The Meson build may not be too polished everywhere, but it should
be fully functional and correct. Most
On Sun, 9 Dec 2018 16:07:22 +0100
Peter Bašista wrote:
> Hi,
>
> Weston does not seem to perform any output scaling unless an explicit and
> correct output name is given.
Hi,
yes, that is correct. A correct output name must be given.
> At least in my case, it was *not* suff
Hi,
Weston does not seem to perform any output scaling unless an explicit and
correct output name is given. At least in my case, it was *not* sufficient
to add the following section to weston.ini:
[output]
scale=2
With such a configuration, weston-launch would launch Weston normally
On Fri, 30 Nov 2018 09:41:54 +0530
deepan muthusamy wrote:
> I have Weston without notify enabled, with this Weston my UI application
> performance is fast.
>
> But I changed to Weston with notify, because I have to start as system
> service. I followed the procedure provided b
I have Weston without notify enabled, with this Weston my UI application
performance is fast.
But I changed to Weston with notify, because I have to start as system
service. I followed the procedure provided by you guys only.
Now my UI application performance has reduced means application gets
arted app2( this is Weston ) also as system service. But in
different tty(tty7).
App1 is depended on app2 to start.
I added that dependency.
App2 is started but app1 not able to find that dependency. Iam getting
error as not able to find weston.
If I start both manually, it's wo
On Mi, 31.10.18 12:51, deepan muthusamy (deepan.m2...@gmail.com) wrote:
> Hi,
> I started app1(this is a UI application) as system service .
> I started app2( this is Weston ) also as system service. But in different
> tty(tty7).
>
> App1 is depended on app2 to start.
> I
Hi,
I started app1(this is a UI application) as system service .
I started app2( this is Weston ) also as system service. But in different
tty(tty7).
App1 is depended on app2 to start.
I added that dependency.
App2 is started but app1 not able to find that dependency. Iam getting
error
On Mon, 15 Oct 2018 13:02:41 +0530
Iqbal Inzamam wrote:
> I'm using Ubuntu 18.04. when i try weston-launch from virtual terminal with
> no weston config file i get an error saying.
> "failed to create input device option 'seat', udev device property ID_SEAT"
> just ru
I'm using Ubuntu 18.04. when i try weston-launch from virtual terminal with
no weston config file i get an error saying.
"failed to create input device option 'seat', udev device property ID_SEAT"
just running weston in normal terminal (within x11) works fine
please help me to run wes
@lists.freedesktop.org
Subject: Re: Launch Weston at tty1
On Wed, 26 Sep 2018 17:59:37 +
"Singh, Satyeshwar" wrote:
> Saw a response from Deepan where he said "I changed type from notify
> to simple. Now problem has been solved. Thank you".
>
Right. That cannot
hanks,
pq
>
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
> Behalf Of Jan Engelhardt
> Sent: Wednesday, September 26, 2018 12:16 AM
> To: deepan muthusamy
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: Lau
8 12:16 AM
To: deepan muthusamy
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: Launch Weston at tty1
On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:
>I can able to launch Weston at tty7 but not able to launch at tty1. Why??
Probably because the tty is already allocated. (
On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:
>I can able to launch Weston at tty7 but not able to launch at tty1. Why??
Probably because the tty is already allocated. (man deallocvt)
___
wayland-devel mailing list
wayland-de
Hi Deepan,
On Wed, 26 Sep 2018 at 06:08, deepan muthusamy wrote:
> I can able to launch Weston at tty7 but not able to launch at tty1. Why??
Again, no idea without any further information. As with your last
mail, please attach logs, exact steps and results, and enough
information to help
I can able to launch Weston at tty7 but not able to launch at tty1. Why??
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
5 Sep 2018 09:28:27 +0800 (CST)
>tugouxp <13824125...@163.com> wrote:
>
>> hi folks:
>>
>>
>> my project take wayland as display server, weston working with
>> libdrm-backend, the opegles and egl interface are provided by arm
>> official provide &q
On Tue, 25 Sep 2018 09:28:27 +0800 (CST)
tugouxp <13824125...@163.com> wrote:
> hi folks:
>
>
> my project take wayland as display server, weston working with
> libdrm-backend, the opegles and egl interface are provided by arm
> official provide "libmali.so&quo
hi folks:
my project take wayland as display server, weston working with
libdrm-backend, the opegles and egl interface are provided by arm official
provide "libmali.so" library.
but now i want to test whether it can be worked that get rid of mali library
completely ,an
Hi Deepan,
Do you have any Weston logs when it restarts? Maybe you want to add --log
option to redirect all output to some log file and share that with us?
-Satyeshwar
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
Behalf Of deepan muthusamy
Sent: Friday, September
ertainly be replaced by a `bool` or at least harmonized,
but that seems worth a separate patch set.
Best regards
Thomas
[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/21
>>
>> section = weston_config_get_section(wc, "core", NULL, NULL);
>>
Hi,
I tried the same thing in the link which you provided. It's starting but
Weston is getting restart for every 90 sec.
My service file is as follows:
[Unit]
Description: launch Weston
Requires= dbus.socket dbus.service systemd-user-sessions.service
After= dbus.socket dbus.service systemd
Hello All,
I have wayland/weston running on several embedded systems and now
updated from weston 4.0 to weston 5.0 and that caused a problem on my
oldest hardware with a Intel N270 Atom and 945GSE "gpu" that use the
Mesa i915 driver. I have other systems with more modern gpu that us
you already tried running it? There is
an example systemd unit file given for running as a system service posted
in this thread, which is the first Google hit for 'weston systemd': have
you tried that?
https://lists.freedesktop.org/archives/wayland-devel/2017-November/035973.html
If this is no
Did you launched as session service?
I want to launch as system service. Have you tried that?
On Tue, 18 Sep 2018, 7:33 pm Andrea Giammarchi,
wrote:
> I've previously tested with this service and it used to work without
> issues:
>
> [Unit] Description=Weston Conflicts=getty@
I've previously tested with this service and it used to work without issues:
[Unit] Description=Weston Conflicts=getty@tty1.service
After=getty@tty1.service systemd-user-sessions.service [Service]
User=YOUR_USER Restart=always RestartSec=2 TimeoutSec=2
EnvironmentFile=/etc/environment ExecStart
Not able to start Weston at bootup as system service.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
ool.
>
> section = weston_config_get_section(wc, "core", NULL, NULL);
> weston_config_section_get_string(section,
[snip]
Same for the other parts of this file.
> diff --git a/man/weston.ini.man b/man/weston.ini.man
> index f237fd60..cc1cb409 100644
> --
It took me longer than I hoped to get back to this, but I have now tested
Quentin Glidic's two patches (the revert followed by the revised fix) plus
my "Restore keyboard focus after VT switch", applied to Weston 4. With all
three patches applied, Weston passes my tests. Hooray!
Hi Daniel ,
Thank you for the resources , I figured it out actually it was a stupid
question . I have opened a merge request on the issue ([1] Support
EGL_KHR_partial_update for performance )if you could check it .
[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/15/diffs
Hi Rohan,
On Sat, 1 Sep 2018 at 11:28, rohan julka wrote:
> how can I check if there is a compilation error after editing the code in
> Weston , apologies for the rookie question I am just trying to understand on
> how to build and run Weston , it seems a bit confusing any h
This series, Acked-by: Sinclair Yeh
On Wed, Sep 05, 2018 at 05:18:15PM -0700, Deepak Rawat wrote:
> Not all drivers support fb2 modifiers so read the capability before
> using drmModeAddFB2WithModifiers.
>
> Signed-off-by: Deepak Rawat
> ---
> libweston/compositor-drm.c | 20
On Thu, 13 Sep 2018 10:32:52 +0530
nsola...@codeaurora.org wrote:
> On 2018-09-12 18:38, Pekka Paalanen wrote:
> > You could write a new Wayland extension, implement it in Weston and
> > your app, and control the compositor state that way. However, generally
> > it is a bad
501 - 600 of 12981 matches
Mail list logo
