observed when running Weston with pixman renderer and
drm-backend
Hi Pritama, Namit,
On Fri, Jul 05, 2024 at 07:14:35AM +, Namit Solanki (QUIC) wrote:
> Hi Weston team,
>
> Can you please let us know if you faced this issue on Weston 10?
No. I've tried this with 10.0.2 and 10.0
> Subject: Blank screen observed when running Weston with pixman renderer and
> drm-backend
>
> Hi Team,
>
> We are observing the following issue on Weston 10.0.2:
>
> When we launch Weston with drm-backend and pixman renderer, we are seeing
> blank screen. Upon doing h
)
Subject: Blank screen observed when running Weston with pixman renderer and
drm-backend
Hi Team,
We are observing the following issue on Weston 10.0.2:
When we launch Weston with drm-backend and pixman renderer, we are seeing blank
screen. Upon doing hotplug, display is coming up.
In layer dumps
Hi Team,
We are observing the following issue on Weston 10.0.2:
When we launch Weston with drm-backend and pixman renderer, we are seeing blank
screen. Upon doing hotplug, display is coming up.
In layer dumps, we can see that a fully opaque layer is getting created during
issue case as shown
Hi Team,
We are observing the following issue on Weston 10.0.2:
When we launch Weston with drm-backend and pixman renderer, we are seeing blank
screen. Upon doing hotplug, display is coming up.
In layer dumps, we can see that a fully opaque layer is getting created during
issue case as shown
Modify existing drm-backend to set_scaling_filter property that
client has requested compositor to do.
drm-backend calls drmset property api of libdrm to do so.
Signed-off-by: Sameer Lattannavar
---
libweston/backend-drm/drm-internal.h | 18
libweston/backend-drm/drm.c
Hi all
Thank you for your feedback.
>From your opinions, the drm backend reserve primary plane for each CRTC to
avoid the failure in hotplug cases. However, as weston already enabled
DRM_CLIENT_CAP_ATOMIC and DRM_CLIENT_CAP_UNIVERSAL_PLANES, the concept of
primary/overlay is no necessary
ht
if the universal planes is enable.
> > > > For example, the kernel define 6 crtcs, and each crtc will have one
> > > > primary type plane, but not all of the crtcs are used by weston_output.
> > > > Some crtcs may never used, if we reserve all the primary type pl
ave one
> > > primary type plane, but not all of the crtcs are used by weston_output.
> > > Some crtcs may never used, if we reserve all the primary type planes as
> > > scanout plane, that could waste some of them.
> > > Could the open source drm backend m
we reserve all the primary type planes as
> > scanout plane, that could waste some of them.
> >
> > Could the open source drm backend modify the logic of judge the overlay
> > plane? let the primary plane equal to overlay plane or judge in
> > drm_output_pr
ome crtcs may never used, if we reserve all the primary type planes as
> > scanout plane, that could waste some of them.
> >
> > Could the open source drm backend modify the logic of judge the overlay
> > plane? let the primary plane equal to overlay plane or judge in
> &
fine 6 crtcs, and each crtc will have one
primary type plane, but not all of the crtcs are used by weston_output.
Some crtcs may never used, if we reserve all the primary type planes as
scanout plane, that could waste some of them.
Could the open source drm backend modify the logic of judge
one primary
type plane, but not all of the crtcs are used by weston_output. Some crtcs
may never used, if we reserve all the primary type planes as scanout
plane, that could waste some of them.
Could the open source drm backend modify the logic of judge the overlay
plane? let the primary plane equa
On Fri, 23 Nov 2018 20:12:53 +0800
zou lan wrote:
> Hi pekka
>
> I check the atomic commit part of the drm backend in weston 5.0. But I am
> not sure if some vendors support one atomic commit to update many CRTCs, so
Hi Nancy,
in my opinion vendors really should support it. If th
Hi pekka
I check the atomic commit part of the drm backend in weston 5.0. But I am
not sure if some vendors support one atomic commit to update many CRTCs, so
I was wondering
if one output repaint to do one atomic commit would match the weston 5.0's
architecture if they don't support i
On Fri, 23 Nov 2018 16:22:56 +0800
zou lan wrote:
> Hi pekka
>
> >>do you mean users as humans or as apps?
> yes. I mean the apps. I think it's no big impact for apps. The major
> changes for weston new version is focus on libweston/drm backend.
Hi Nancy,
Weston an
Hi pekka
>>do you mean users as humans or as apps?
yes. I mean the apps. I think it's no big impact for apps. The major
changes for weston new version is focus on libweston/drm backend.
I still want to ask something about drm backend. About on_drm_input()
function in compositor-drm
On Tue, 20 Nov 2018 20:32:53 +0800
zou lan wrote:
> Hi pekka
>
> Thank you so much to explain the drm backend details. I ask these because
> some company may implement their own drm backend, changes on interfaces
> between libweston
> and drm backend may increase the merge ef
Hi pekka
Thank you so much to explain the drm backend details. I ask these because
some company may implement their own drm backend, changes on interfaces
between libweston
and drm backend may increase the merge effort.
Could I also ask is weston backward compatible from weston 2.0 to weston
5.0
On Tue, 20 Nov 2018 17:37:34 +0800
zou lan wrote:
> Hi pekka
>
> Thank you for your reply. I have other questions about drm backend.
> I find weston 5.0 modify so much about drm backend and the interfaces of
> compositor communicate with drm backend.
> Is there any docum
Hi pekka
Thank you for your reply. I have other questions about drm backend.
I find weston 5.0 modify so much about drm backend and the interfaces of
compositor communicate with drm backend.
Is there any documents about the drm backend design?
Why compositor need to add a structure weston_head
On Fri, 20 Jul 2018 20:03:35 +0100
Daniel Stone wrote:
> Add a 'drm-debug' scope which prints verbose information about the DRM
> backend's repaint cycle, including the decision tree on how views are
> assigned (or not) to planes.
>
> Signed-off-by: Daniel Stone
> ---
> libweston/compositor-dr
drm_debug(b, "\t[repaint] could not build planes-only "
+"state, trying mixed\n");
state = drm_output_propose_state(output_base,
pending_state,
Hi,
Another revision after Pekka's review. There is a memory leak fix in
testing atomic commits, as well as cosmetic changes inside
drm_output_propose_state.
The largest change is that if we enter drm_output_propose_state in
renderer-only mode, we no longer return early. This matches the
documenta
Hi,
I believe this should resolve all the issues Pekka pointed out in the
(too hurried) v18. It's also been split up into a few different patches
with much more detailed commit messages, so should be much easier to
reason about and review.
Cheers,
Daniel
_
Hi,
Another re-send after Pekka's comments on the modifiers patches. Patches
01-12 from the last series were merged after the last round.
Patch 1 is new; patches 2 and 3 were extracted from patches 5 and 6.
Patches 4-6 have otherwise seen changes after Pekka's review; all the
comments were addres
Hi,
This is v16 (this time for sure) of the atomic series.
Patches 1 and 2 are new, falling out of previous review.
Patch 5 is a bit less trusting, and now properly clips to CRTC bounds if
required.
Similarly, I've gone through patch 8 and am more confident that it
actually does the right thing
> > > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank
> > > screen on a machine with intel hd4400 graphics when staring with:
> > >
> > > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id
> > > -u) weston-launch >weston.log 2>&1
> > >
> > > X works fine and, a cou
On Wed, 11 Apr 2018 08:35:22 +
John Frankish wrote:
> > Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a
> > machine with intel
> > hd4400 graphics when staring with:
> >
> > WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u)
> > weston-launch
> Using mesa-18.0.0, Wayland-1.14 and Weston 3.0.0 I get a blank screen on a
> machine with intel
> hd4400 graphics when staring with:
>
> WAYLAND_DEBUG=1 EGL_LOG_LEVEL=debug XDG_RUNTIME_DIR=/run/user/$(id -u)
> weston-launch >weston.log 2>&1
>
> X works fine and, a couple of mesa upgrades ago,
22:03:44.040] Output repaint window is 7 ms maximum.
[22:03:44.040] Loading module '/usr/local/lib/libweston-3/drm-backend.so'
[22:03:44.044] initializing drm backend
[22:03:44.045] using /dev/dri/card0
[22:03:44.045] Loading module '/usr/local/lib/libweston-3/gl-renderer.so'
.
> On 9 Feb 2018, at 15.07, Pekka Paalanen wrote:
>
> From: Pekka Paalanen
>
> Hi,
>
> here are some patches I extracted from my clone mode series. These are
> building on top of
> https://patchwork.freedesktop.org/series/37994/
> in case that makes any difference.
>
> Patch 1 is a slight cha
From: Pekka Paalanen
Hi,
here are some patches I extracted from my clone mode series. These are
building on top of
https://patchwork.freedesktop.org/series/37994/
in case that makes any difference.
Patch 1 is a slight change in behaviour, patches 2-4 and 6 just split code
into new functions, pa
On Mon, 4 Dec 2017 20:02:48 +
Daniel Stone wrote:
> Hi Pekka,
>
> On 28 March 2017 at 16:26, Pekka Paalanen wrote:
> > Developers with testing rigs having multiple graphics cards plugged in
> > often want to test things on a specific card. We have ways to choose a
> > card through seat assi
Hi Pekka,
On 28 March 2017 at 16:26, Pekka Paalanen wrote:
> Developers with testing rigs having multiple graphics cards plugged in
> often want to test things on a specific card. We have ways to choose a
> card through seat assignments, but configuring that run by run is
> awkward.
>
> Add a com
On Wednesday, August 2, 2017 11:09:44 PM EDT nerdopolis wrote:
> Hi
>
> I found out how to get the systemd session-seat to be my desired seat (with
> --setenv=XDG_SEAT=seatx of which pam_systemd.so responds to) After assigning
> devices to the seat, and trying to start it I get "logind: session n
Hi
I found out how to get the systemd session-seat to be my desired seat (with
--setenv=XDG_SEAT=seatx of which pam_systemd.so responds to) After assigning
devices to the seat, and trying to start it I get "logind: session not running
on a VT"
Of which is a bit confusing as as far as I understan
On Thu, Jul 13, 2017 at 03:50:56PM +0200, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> > Dear All,
> >
> > I am looking for an solution to have early smooth splashscreen on the
> > Linux system with Weston and drm-backend.
> >
>
Hi Matt,
On 17 July 2017 at 20:39, Matt Hoosier wrote:
> Also beware that the DRM backend of Weston will aggressively set the mode
> before you have any chance to paint user-defined content of your own in a
> Wayland client program. So there will still be some window of time during
>
l,
> > >>
> > >> I am looking for an solution to have early smooth splashscreen on the
> > >> Linux system with Weston and drm-backend.
> > >>
> > >> I tried showing splashscreen using Linux logo and fbcon Linux features
> > >> but i
screen on the
> >> Linux system with Weston and drm-backend.
> >>
> >> I tried showing splashscreen using Linux logo and fbcon Linux features
> >> but it is not smooth as when system boots logo gets displayed via
> >> kernel and as the Weston starts
> >&
On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
>> Dear All,
>>
>> I am looking for an solution to have early smooth splashscreen on the
>> Linux system with Weston and drm-backend.
>>
>> I trie
On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote:
> Dear All,
>
> I am looking for an solution to have early smooth splashscreen on the
> Linux system with Weston and drm-backend.
>
> I tried showing splashscreen using Linux logo and fbcon Linux features
> but it is not
Dear All,
I am looking for an solution to have early smooth splashscreen on the
Linux system with Weston and drm-backend.
I tried showing splashscreen using Linux logo and fbcon Linux features
but it is not smooth as when system boots logo gets displayed via
kernel and as the Weston starts
I see
On 4/6/17 2:09 PM, Pekka Paalanen wrote:
From: Pekka Paalanen
The pkg-config test for LIBDRM is independent of whether the DRM backend
is enabled or not. Therefore it is possible to have libdrm available and
found, even though it is not needed.
Do not link libdrm.so into the launchers unless
From: Pekka Paalanen
The pkg-config test for LIBDRM is independent of whether the DRM backend
is enabled or not. Therefore it is possible to have libdrm available and
found, even though it is not needed.
Do not link libdrm.so into the launchers unless it is really needed,
that is, DRM
From: Pekka Paalanen
Developers with testing rigs having multiple graphics cards plugged in
often want to test things on a specific card. We have ways to choose a
card through seat assignments, but configuring that run by run is
awkward.
Add a command line option for opening a specific DRM devic
This is a complete port of the DRM backend that uses
the recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from the configuration
file using previously
On 15.09.2016 13:37, Pekka Paalanen wrote:
> On Wed, 14 Sep 2016 11:50:34 +0200
> Armin Krezović wrote:
>
>> On 13.09.2016 12:49, Pekka Paalanen wrote:
>>> On Thu, 18 Aug 2016 18:42:32 +0200
>>> Armin Krezović wrote:
>>>
>>>> This is a co
On Wed, 14 Sep 2016 11:50:34 +0200
Armin Krezović wrote:
> On 13.09.2016 12:49, Pekka Paalanen wrote:
> > On Thu, 18 Aug 2016 18:42:32 +0200
> > Armin Krezović wrote:
> >
> >> This is a complete port of the DRM backend that uses
> >> recent
On 13.09.2016 12:49, Pekka Paalanen wrote:
> On Thu, 18 Aug 2016 18:42:32 +0200
> Armin Krezović wrote:
>
>> This is a complete port of the DRM backend that uses
>> recently added output handling API for output
>> configuration.
>>
>> Output can
Hi
Found a few typos mentioned below.
On Thu, Aug 18, 2016 at 6:42 PM, Armin Krezović
wrote:
> This is a complete port of the DRM backend that uses
> recently added output handling API for output
*the* recently added [...]
> configuration.
>
> Output can be configured at run
On Thu, 18 Aug 2016 18:42:32 +0200
Armin Krezović wrote:
> This is a complete port of the DRM backend that uses
> recently added output handling API for output
> configuration.
>
> Output can be configured at runtime by passing the
> necessary configuration parameters, which
This is a complete port of the DRM backend that uses
recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from the configuration
file using previously added
On Sun, 14 Aug 2016 17:28:13 +0200
Armin Krezović wrote:
> This is a complete port of the DRM backend that uses
> recently added output handling API for output
> configuration.
>
> Output can be configured at runtime by passing the
> necessary configuration parameters, which
On 14/08/2016 17:28, Armin Krezović wrote:
This is a complete port of the DRM backend that uses
recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from
This is a complete port of the DRM backend that uses
recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from the configuration
file using previously added
On 12.08.2016 13:28, Quentin Glidic wrote:
> On 11/08/2016 17:33, Armin Krezović wrote:
>> This is a complete port of the DRM backend that uses
>> recently added output handling API for output
>> configuration.
>>
>> Output can be configured at runtime by passi
On 11/08/2016 17:33, Armin Krezović wrote:
This is a complete port of the DRM backend that uses
recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from
This is a complete port of the DRM backend that uses
recently added output handling API for output
configuration.
Output can be configured at runtime by passing the
necessary configuration parameters, which can be
filled in manually or obtained from the configuration
file using previously added
On Sat, 30 Apr 2016 11:35:22 +0200
Benoit Gschwind wrote:
> Hello Bryce,
>
> I have some comments after a trivial rebase.
>
> Le 30/04/2016 00:40, Bryce Harrington a écrit :
> > From: Giulio Camuffo
> >
> > Signed-off-by: Bryce Harrington
> > Reviewed-by: Quentin Glidic
> > Acked-by: Pekka
, mode, &config,
> + &crtc_mode);
> if (!current)
> goto err_free;
> output->base.current_mode = ¤t->base;
> @@ -2399,7 +2354,7 @@ create_output_for_connector(struct drm_backend *b,
>
>
);
b->connector_allocator &= ~(1 << output->connector_id);
free(output);
+ free(config.modeline);
return -1;
}
@@ -2744,6 +2700,10 @@ drm_destroy(struct weston_compositor *ec)
close(b->drm.fd);
+ free(b->config->gbm_format);
+ fr
On Sun, Apr 17, 2016 at 01:26:58PM +0300, Giulio Camuffo wrote:
> Hi,
>
> I don't understand this one at all, you're moving configuration back
> into the backend, partially reverting patch 5.
This was done to implement the change Benoit requested in the v5 series
for tracking gbm_format as its en
On Sun, 17 Apr 2016 13:26:58 +0300
Giulio Camuffo wrote:
> Hi,
>
> I don't understand this one at all, you're moving configuration back
> into the backend, partially reverting patch 5.
>
Hi,
indeed, the very reason we are working on this patch series is to take
all .ini file parsing, struct w
On Sat, 16 Apr 2016 08:49:22 +0300
Giulio Camuffo wrote:
> 2016-04-16 1:02 GMT+03:00 Bryce Harrington :
> > On Fri, Apr 15, 2016 at 02:32:04PM +0200, Benoit Gschwind wrote:
> >> > + /** The seat to be used by the output. Set to NULL to use the
> >> > +* default seat. */
> >> > + char *s
+2338,15 @@ create_output_for_connector(struct drm_backend *b,
>> goto err_free;
>> }
>>
>> - if (config == OUTPUT_CONFIG_OFF) {
>> + if (mode == WESTON_DRM_BACKEND_OUTPUT_OFF) {
>> weston_log("Disa
ose_initial_mode(b, output, mode, &config,
> +&crtc_mode);
> if (!current)
> goto err_free;
> output->base.current_mode = ¤t->base;
> @@ -2399,7 +2354,7 @@ create_output_for_connector(
Hi,
I don't understand this one at all, you're moving configuration back
into the backend, partially reverting patch 5.
2016-04-16 6:28 GMT+03:00 Bryce Harrington :
> Signed-off-by: Bryce Harrington
> ---
> src/compositor-drm.c | 93
>
> src
2016-04-16 1:02 GMT+03:00 Bryce Harrington :
> On Fri, Apr 15, 2016 at 02:32:04PM +0200, Benoit Gschwind wrote:
>> > + /** The seat to be used by the output. Set to NULL to use the
>> > +* default seat. */
>> > + char *seat;
>> > + /** The modeline to be used by the output. Refer to the d
eems to need more discussion.
>
> PATCH 10/11
>
> The patch look to address issue of PATCH 07/11 that Pekka raised about
> freeing config variable.
>
> PATCH 11/11
>
> Look fine.
>
> Reviewed-by: Benoit Gschwind
>
>
>
> [1] git node: 94cb06a20813
On Wed, Apr 13, 2016 at 05:21:39PM +0300, Pekka Paalanen wrote:
> On Wed, 13 Apr 2016 03:25:04 -0700
> Bryce Harrington wrote:
>
> > In following up on my earlier update of Giulio's drm backend config
> > patch, I've taken the liberty to try and also integrate
Signed-off-by: Bryce Harrington
---
src/compositor-drm.c | 93
src/compositor-drm.h | 41 ---
src/main.c | 43
3 files changed, 80 insertions(+), 97 deletions(-)
diff --git a/src/composito
_allocator &= ~(1 << output->connector_id);
free(output);
+ free(config.modeline);
return -1;
}
@@ -2744,6 +2700,10 @@ drm_destroy(struct weston_compositor *ec)
close(b->drm.fd);
+ free(b->config->gbm_format);
+ free(b->config-&
On Fri, Apr 15, 2016 at 02:32:04PM +0200, Benoit Gschwind wrote:
> > + /** The seat to be used by the output. Set to NULL to use the
> > +* default seat. */
> > + char *seat;
> > + /** The modeline to be used by the output. Refer to the documentation
> > +* of WESTON_DRM_BACKEND_OUTPU
On Fri, Apr 15, 2016 at 12:01:01PM +0300, Pekka Paalanen wrote:
> On Thu, 14 Apr 2016 19:09:34 +0300
> Giulio Camuffo wrote:
>
> > 2016-04-13 14:30 GMT+03:00 Pekka Paalanen :
> > > On Tue, 12 Apr 2016 21:34:28 -0700
> > > Bryce Harrington wrote:
> > >
> > >> On Wed, Apr 06, 2016 at 11:37:57AM
On Fri, Apr 15, 2016 at 12:01:01PM +0300, Pekka Paalanen wrote:
> On Thu, 14 Apr 2016 19:09:34 +0300
> Giulio Camuffo wrote:
>
> > 2016-04-13 14:30 GMT+03:00 Pekka Paalanen :
> > > On Tue, 12 Apr 2016 21:34:28 -0700
> > > Bryce Harrington wrote:
> > >
> > >> On Wed, Apr 06, 2016 at 11:37:57AM
e.
>
> Reviewed-by: Benoit Gschwind
>
>
>
> [1] git node: 94cb06a208130b0ee16553a2cd513e5e7d67f368
>
>
>
> Le 13/04/2016 12:25, Bryce Harrington a écrit :
> > In following up on my earlier update of Giulio's drm backend config
> > patch, I'v
; }
> >
> > - if (config == OUTPUT_CONFIG_OFF) {
> > + if (mode == WESTON_DRM_BACKEND_OUTPUT_OFF) {
> > weston_log("Disabling output %s\n", output->base.name);
> > drmModeSetCrtc(b->drm.fd, output->crtc_id,
> >
On Fri, 15 Apr 2016 14:32:04 +0200
Benoit Gschwind wrote:
> Hello Bryce and Giulio,
>
> Thanks for your contribution :), here is my comments.
>
> Le 13/04/2016 12:25, Bryce Harrington a écrit :
> > From: Giulio Camuffo
> >
> > Signed-off-by: Bryce Harrington
> > Reviewed-by: Quentin Glidic
rit :
> In following up on my earlier update of Giulio's drm backend config
> patch, I've taken the liberty to try and also integrate a couple of
> Benoit's other backend configuration patches into this patchset.
>
> Giulio and Benoit took different approaches in th
_mode, &modeline);
> + current = drm_output_choose_initial_mode(b, output, mode, &config,
> + &crtc_mode);
> if (!current)
> goto err_free;
> output->base.current_mode = ¤t->base;
> @@ -2399,7 +2354,7 @@
On Thu, 14 Apr 2016 19:09:34 +0300
Giulio Camuffo wrote:
> 2016-04-13 14:30 GMT+03:00 Pekka Paalanen :
> > On Tue, 12 Apr 2016 21:34:28 -0700
> > Bryce Harrington wrote:
> >
> >> On Wed, Apr 06, 2016 at 11:37:57AM +0300, Pekka Paalanen wrote:
> >> > On Wed, 9 Mar 2016 16:49:29 -0800
> >> >
2016-04-13 14:30 GMT+03:00 Pekka Paalanen :
> On Tue, 12 Apr 2016 21:34:28 -0700
> Bryce Harrington wrote:
>
>> On Wed, Apr 06, 2016 at 11:37:57AM +0300, Pekka Paalanen wrote:
>> > On Wed, 9 Mar 2016 16:49:29 -0800
>> > Bryce Harrington wrote:
>> >
>> > > From: Giulio Camuffo
>> > >
>> > > Sign
On Wed, 13 Apr 2016 03:25:04 -0700
Bryce Harrington wrote:
> In following up on my earlier update of Giulio's drm backend config
> patch, I've taken the liberty to try and also integrate a couple of
> Benoit's other backend configuration patches into this patchset.
>
On Tue, 12 Apr 2016 21:34:28 -0700
Bryce Harrington wrote:
> On Wed, Apr 06, 2016 at 11:37:57AM +0300, Pekka Paalanen wrote:
> > On Wed, 9 Mar 2016 16:49:29 -0800
> > Bryce Harrington wrote:
> >
> > > From: Giulio Camuffo
> > >
> > > Signed-off-by: Bryce Harrington
> > > Reviewed-by: Quen
In following up on my earlier update of Giulio's drm backend config
patch, I've taken the liberty to try and also integrate a couple of
Benoit's other backend configuration patches into this patchset.
Giulio and Benoit took different approaches in their implementations.
I&
@ -2744,6 +2700,10 @@ drm_destroy(struct weston_compositor *ec)
close(b->drm.fd);
+ free(b->config->gbm_format);
+ free(b->config->seat_id);
+ free(b->config);
+
free(b);
}
@@ -3067,15 +3027,13 @@ renderer_switch_binding(struct wes
param = { 0, };
> > -
> > - const struct weston_option drm_options[] = {
> > - { WESTON_OPTION_INTEGER, "connector", 0, ¶m.connector },
> > - { WESTON_OPTION_STRING, "seat", 0, ¶m.seat_id },
> > - { WESTON_OPTION_I
\
> >> $(INPUT_BACKEND_SOURCES)\
> >> shared/helpers.h\
> >> shared/timespec-util.h \
> >> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> >> index e01f6b9..111c882 100644
>
ACKEND_SOURCES)\
>> shared/helpers.h\
>> shared/timespec-util.h \
>> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
>> index e01f6b9..111c882 100644
>> --- a/src/compositor-drm.c
>> +++ b
- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -2185,30 +2162,45 @@ get_gbm_format_from_section(struct
> weston_config_section *section,
> * Find the most suitable mode to use for initial setup (or reconfiguration
> on
> * hotplug etc) for a DRM output.
> *
> + * @
ion_get_string(section,
> -"gbm-format", &s, NULL);
> -
> if (s == NULL)
> *format = default_value;
> else if (strcmp(s, "xrgb") == 0)
> @@ -2174,8 +2153,6 @@ get_gbm_format_from_section(struct
I've updated Giulio's drm backend config patch to apply to trunk, and
added three changes Pekka identified as needed: A compiler warning about
missing braces is quelled[1], a major/minor versioning scheme[2] is
added for the config structure to keep track of ABI changes, and a note
i
,
* Find the most suitable mode to use for initial setup (or reconfiguration on
* hotplug etc) for a DRM output.
*
+ * @param backend The DRM backend object
* @param output DRM output to choose mode for
- * @param kind Strategy and preference to use when choosing mode
- * @param width Desire
On Tue, 24 Nov 2015 16:31:42 +0200
Giulio Camuffo wrote:
> 2015-11-20 11:38 GMT+02:00 Quentin Glidic :
> > For now, I will just comment on the part I am not too happy with.
> >
> > On 31/10/2015 12:08, Giulio Camuffo wrote:
> >>
> >> [snip]
> >> +static void
> >> +drm_configure_output(struct w
RE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef SRC_COMPOSITOR_DRM_STATIC_H_
+#define SRC_COMPOSITOR_DRM_STATIC_H_
+
+#include
+
+struct weston_drm_backend_output_config {
+ struct weston_backend_output_config base;
+
+ struct wl_list link; /* link defined output from config fil
Le 09/02/2016 11:38, Pekka Paalanen a écrit :
On Tue, 9 Feb 2016 01:11:48 +0100
Benoit Gschwind wrote:
Hello,
while I developing the option 2. I raise few questions because this
option explicit the fact that back-ends does not share the same API (at
less for the configuration). To resolve t
at;
+ /** The seat to be used by the output. Set to NULL to use the
+* default seat. */
+ char *seat;
+ /** The modeline to be used by the output. Refer to the documentation
+* of WESTON_DRM_BACKEND_OUTPUT_PREFERRED for details. */
+ char *modeline;
+
On Tue, 9 Feb 2016 01:11:48 +0100
Benoit Gschwind wrote:
> Hello,
>
> while I developing the option 2. I raise few questions because this
> option explicit the fact that back-ends does not share the same API (at
> less for the configuration). To resolve the issue I found the following
> optio
1 - 100 of 166 matches
Mail list logo
