On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen wrote:
>
> there is a single, unambiguous answer on Wayland: the compositor owns
> the pipeline. Therefore we won't have the kind of problems you describe
> above.
>
> These are the very reasons I am against adding any kind of protocol
> extension tha
On Fri, 22 Feb 2019 14:18:44 -0700
Chris Murphy wrote:
> On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen wrote:
> >
> > Hi Chris,
> >
> > that is some interesting background, but I feel like I didn't quite
> > catch the point.
> >
> > If the CRTC color management pipeline (LUT-CTM-LUT + maybe mor
equires explicit
support from clients, and application toolkits usually do not have that.
> > 2. As I have read at multiple places that weston supports multi-display
> > for drm based devices, is it also possible for fbdev backend, or it has
> > some functionality constraint tha
a
client can ask to be placed fullscreen on a particular output using the
fullscreen-shell protocol
2. As I have read at multiple places that weston supports multi-display
for drm based devices, is it also possible for fbdev backend, or it has
some functionality constraint that do not let
somebody point me to an example implementation of such client?
2. As I have read at multiple places that weston supports multi-display for
drm based devices, is it also possible for fbdev backend, or it has some
functionality constraint that do not let that to work on fbdev?
3. I am actually using
On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen wrote:
>
> Hi Chris,
>
> that is some interesting background, but I feel like I didn't quite
> catch the point.
>
> If the CRTC color management pipeline (LUT-CTM-LUT + maybe more) is
> programmed according to the monitor's color profile, where would
ution 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 a
Vlad wrote:
> Hi,
>
> FYI, The links at the end all give 404. Releases page is missing alpha
> version entry as well.
>
> On 2/19/19 10:15 PM, Derek Foreman wrote:
> > This is the alpha release for weston 6.0. A lot has happened for this
> > release, some big items to
This is the alpha release for weston 6.0. A lot has happened for this
release, some big items to note are:
We now have xdg-shell stable support!
We've moved to meson as our primary build system and have deprecated the
autotools build entirely. You need to run configure with
--enable-auto
Hello,
Thanks everyone for the flurry of activity reviewing and landing important
patches for the release!
In agreement with Daniel's suggestion to freeze and release today, I'm
going to start rolling the alpha shortly. Here's the final release
schedule:
Alpha: today, February 19th
Beta: March
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 gamma
> ramps.
Short version:
Having just briefly looked that code, my b
Hello Chris,
Am 31.01.19 um 20:03 schrieb Chris Murphy:
> On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
> wrote:
>> From where can the client-applications get the ICC profile files? Does
>> the client application manufacture it for a given color space and a
>> standard template?
> I'm prett
Chris Murphy wrote:
Hi Chris,
> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/
right, but colord is not needed to run X11 color management.
27;s the nature of system provided color management. A client
that implicitly or explicitly uses the system facility gets
the plain vanilla fallback. Any application that wants to have
more control can do so, by doing its own conversions to the
specific display space. Profile installation is a users
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
nd distribution 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
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 gener
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 application
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 enab
, 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 Hutter
ck works just as well and has the benefit of
working with pre-releases (or patched versions) where needed. Esp. because
here we just look for a single API call here. Do you have a preference?
> > +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> > +
>
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
pointe
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(
> +
e gets replaced with a version check after libinput is
released?
> +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> +
> dep_libm = cc.find_library('m')
> dep_libdl = cc.find_library('dl&#
general application usage as it
needs to be privileged and exclusive
- it assumes that 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
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 re
version it just has to label its test RGB values with a known
source space 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 exampl
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 cam
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
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
able fbdev on your distro 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
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 see
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 a
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
.g. investigating a 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
out 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 would seem too
useful to ignore.
Thanks,
pq
>
> [1]
> https://lists.freedesktop.org/archives/wayland-devel/20
of users now probably is 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 withou
roaches 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
___
w
ill. 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 workin
n changes 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 pe
>>> 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
wise I still see
them as two completely orthogonal features, and we need to split the
work into 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
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
lon
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
> m
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 ou
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 render
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
he target
> 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
compos
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
> > composit
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 know
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
ion. So probably 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
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 would
ward compatibility 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
ht
> 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
tran
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 pon
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 sol
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
/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
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 missing
,
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
ail 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
#x27;s used for test 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-headle
gt;
> 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 t
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
r 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.
Thanks,
ma.
___
wayl
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.fr
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 options are e
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
f either of the following commands:
1. weston
2. weston --debug
3. weston-launch
4. weston-launch -v
When I tried to run "weston --scale=2", the following error message
appeared:
fatal: unhandled option: --scale=2
which prompted me to investigate further. I have tried to specify th
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, but
there
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
2( 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'
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 as not
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&quo
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 hel
@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
501 - 600 of 14114 matches
Mail list logo
