date:20151031

[PATCH weston v2] drm: port the drm backend to the new init api

2015-10-31 Thread Giulio Camuffo

---
 Makefile.am  |   3 +
 src/compositor-drm.c | 234 ---
 src/compositor-drm.h |  87 +++
 src/main.c   | 127 +++-
 4 files changed, 290 insertions(+), 161 deletions(-)
 create mode 100644 src/compositor-drm.h

diff --git a/Makefile.am b/Makefile.am
index 55e3bcb..b2238ea 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -72,6 +72,7 @@ weston_SOURCES =  \
src/log.c   \
src/compositor.c\
src/compositor.h\
+   src/compositor-drm.h\
src/input.c \
src/data-device.c   \
src/screenshooter.c \
@@ -209,6 +210,7 @@ westonincludedir = $(includedir)/weston
 westoninclude_HEADERS =\
src/version.h   \
src/compositor.h\
+   src/compositor-drm.h\
src/timeline-object.h   \
shared/matrix.h \
shared/config-parser.h  \
@@ -278,6 +280,7 @@ drm_backend_la_CFLAGS = \
$(AM_CFLAGS)
 drm_backend_la_SOURCES =   \
src/compositor-drm.c\
+   src/compositor-drm.h\
$(INPUT_BACKEND_SOURCES)\
shared/helpers.h\
shared/timespec-util.h  \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 41f9a82..85e8b04 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -50,6 +50,7 @@
 #include "shared/timespec-util.h"
 #include "libbacklight.h"
 #include "compositor.h"
+#include "compositor-drm.h"
 #include "gl-renderer.h"
 #include "pixman-renderer.h"
 #include "libinput-seat.h"
@@ -74,17 +75,6 @@
 #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
 #endif
 
-static int option_current_mode = 0;
-
-enum output_config {
-   OUTPUT_CONFIG_INVALID = 0,
-   OUTPUT_CONFIG_OFF,
-   OUTPUT_CONFIG_PREFERRED,
-   OUTPUT_CONFIG_CURRENT,
-   OUTPUT_CONFIG_MODE,
-   OUTPUT_CONFIG_MODELINE
-};
-
 struct drm_backend {
struct weston_backend base;
struct weston_compositor *compositor;
@@ -107,6 +97,7 @@ struct drm_backend {
uint32_t connector_allocator;
struct wl_listener session_listener;
uint32_t format;
+   bool option_current_mode;
 
/* we need these parameters in order to not fail drmModeAddFB2()
 * due to out of bounds dimensions, and then mistakenly set
@@ -130,6 +121,10 @@ struct drm_backend {
 
int32_t cursor_width;
int32_t cursor_height;
+
+   void (*configure_output)(struct weston_compositor *compositor,
+const char *name,
+struct weston_drm_backend_output_config 
*config);
 };
 
 struct drm_mode {
@@ -220,13 +215,6 @@ struct drm_sprite {
uint32_t formats[];
 };
 
-struct drm_parameters {
-   int connector;
-   int tty;
-   int use_pixman;
-   const char *seat_id;
-};
-
 static struct gl_renderer_interface *gl_renderer;
 
 static const char default_seat[] = "seat0";
@@ -2066,47 +2054,26 @@ find_and_parse_output_edid(struct drm_backend *b,
 
 
 
-static int
-parse_modeline(const char *s, drmModeModeInfo *mode)
-{
-   char hsync[16];
-   char vsync[16];
-   float fclock;
-
-   mode->type = DRM_MODE_TYPE_USERDEF;
-   mode->hskew = 0;
-   mode->vscan = 0;
-   mode->vrefresh = 0;
-   mode->flags = 0;
-
-   if (sscanf(s, "%f %hd %hd %hd %hd %hd %hd %hd %hd %15s %15s",
-  ,
-  >hdisplay,
-  >hsync_start,
-  >hsync_end,
-  >htotal,
-  >vdisplay,
-  >vsync_start,
-  >vsync_end,
-  >vtotal, hsync, vsync) != 11)
-   return -1;
-
-   mode->clock = fclock * 1000;
-   if (strcmp(hsync, "+hsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_PHSYNC;
-   else if (strcmp(hsync, "-hsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_NHSYNC;
-   else
-   return -1;
+static void
+weston_modeline_to_drm(struct weston_drm_backend_modeline *modeline,
+  drmModeModeInfo *drm_mode)
+{
+   drm_mode->type = DRM_MODE_TYPE_USERDEF;
+   drm_mode->hskew = 0;
+   drm_mode->vscan = 0;
+   drm_mode->vrefresh = 0;
+   drm_mode->flags = modeline->flags;
+   drm_mode->clock = modeline->clock;
 
-   if (strcmp(vsync, "+vsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_PVSYNC;
-   else if (strcmp(vsync, "-vsync") == 0)

[PATCH weston v3] drm: port the drm backend to the new init api

2015-10-31 Thread Giulio Camuffo

---

v3: fixed warning after rebase

 Makefile.am  |   3 +
 src/compositor-drm.c | 234 ---
 src/compositor-drm.h |  87 +++
 src/main.c   | 129 +++-
 4 files changed, 292 insertions(+), 161 deletions(-)
 create mode 100644 src/compositor-drm.h

diff --git a/Makefile.am b/Makefile.am
index 55e3bcb..b2238ea 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -72,6 +72,7 @@ weston_SOURCES =  \
src/log.c   \
src/compositor.c\
src/compositor.h\
+   src/compositor-drm.h\
src/input.c \
src/data-device.c   \
src/screenshooter.c \
@@ -209,6 +210,7 @@ westonincludedir = $(includedir)/weston
 westoninclude_HEADERS =\
src/version.h   \
src/compositor.h\
+   src/compositor-drm.h\
src/timeline-object.h   \
shared/matrix.h \
shared/config-parser.h  \
@@ -278,6 +280,7 @@ drm_backend_la_CFLAGS = \
$(AM_CFLAGS)
 drm_backend_la_SOURCES =   \
src/compositor-drm.c\
+   src/compositor-drm.h\
$(INPUT_BACKEND_SOURCES)\
shared/helpers.h\
shared/timespec-util.h  \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 41f9a82..85e8b04 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -50,6 +50,7 @@
 #include "shared/timespec-util.h"
 #include "libbacklight.h"
 #include "compositor.h"
+#include "compositor-drm.h"
 #include "gl-renderer.h"
 #include "pixman-renderer.h"
 #include "libinput-seat.h"
@@ -74,17 +75,6 @@
 #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
 #endif
 
-static int option_current_mode = 0;
-
-enum output_config {
-   OUTPUT_CONFIG_INVALID = 0,
-   OUTPUT_CONFIG_OFF,
-   OUTPUT_CONFIG_PREFERRED,
-   OUTPUT_CONFIG_CURRENT,
-   OUTPUT_CONFIG_MODE,
-   OUTPUT_CONFIG_MODELINE
-};
-
 struct drm_backend {
struct weston_backend base;
struct weston_compositor *compositor;
@@ -107,6 +97,7 @@ struct drm_backend {
uint32_t connector_allocator;
struct wl_listener session_listener;
uint32_t format;
+   bool option_current_mode;
 
/* we need these parameters in order to not fail drmModeAddFB2()
 * due to out of bounds dimensions, and then mistakenly set
@@ -130,6 +121,10 @@ struct drm_backend {
 
int32_t cursor_width;
int32_t cursor_height;
+
+   void (*configure_output)(struct weston_compositor *compositor,
+const char *name,
+struct weston_drm_backend_output_config 
*config);
 };
 
 struct drm_mode {
@@ -220,13 +215,6 @@ struct drm_sprite {
uint32_t formats[];
 };
 
-struct drm_parameters {
-   int connector;
-   int tty;
-   int use_pixman;
-   const char *seat_id;
-};
-
 static struct gl_renderer_interface *gl_renderer;
 
 static const char default_seat[] = "seat0";
@@ -2066,47 +2054,26 @@ find_and_parse_output_edid(struct drm_backend *b,
 
 
 
-static int
-parse_modeline(const char *s, drmModeModeInfo *mode)
-{
-   char hsync[16];
-   char vsync[16];
-   float fclock;
-
-   mode->type = DRM_MODE_TYPE_USERDEF;
-   mode->hskew = 0;
-   mode->vscan = 0;
-   mode->vrefresh = 0;
-   mode->flags = 0;
-
-   if (sscanf(s, "%f %hd %hd %hd %hd %hd %hd %hd %hd %15s %15s",
-  ,
-  >hdisplay,
-  >hsync_start,
-  >hsync_end,
-  >htotal,
-  >vdisplay,
-  >vsync_start,
-  >vsync_end,
-  >vtotal, hsync, vsync) != 11)
-   return -1;
-
-   mode->clock = fclock * 1000;
-   if (strcmp(hsync, "+hsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_PHSYNC;
-   else if (strcmp(hsync, "-hsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_NHSYNC;
-   else
-   return -1;
+static void
+weston_modeline_to_drm(struct weston_drm_backend_modeline *modeline,
+  drmModeModeInfo *drm_mode)
+{
+   drm_mode->type = DRM_MODE_TYPE_USERDEF;
+   drm_mode->hskew = 0;
+   drm_mode->vscan = 0;
+   drm_mode->vrefresh = 0;
+   drm_mode->flags = modeline->flags;
+   drm_mode->clock = modeline->clock;
 
-   if (strcmp(vsync, "+vsync") == 0)
-   mode->flags |= DRM_MODE_FLAG_PVSYNC;
-   else

FOSDEM16: Graphics DevRoom: call for speakers.

2015-10-31 Thread Luc Verhaegen

Hi,

At FOSDEM on sunday 31st of january 2016, there will be another graphics 
DevRoom. URL: https://fosdem.org/2016/

At first, I wanted to skip another year (like in 2011), as speaker 
turn-out was disgracefully low last year. But when i heard from some 
usual speaker suspects earlier this month (the first time anyone asked 
me about a FOSDEM16 devroom btw), followed by the fact that the devroom 
request deadline was sheduled a month later than the last few years, i 
did end up filing, but this time for a single day only. Claiming two 
days would simply not have been fair towards all the other projects 
that usually get rejected (FOSDEM typically rejects half the requests, 
leading to only about 25 devrooms in parallel). Anyway...

The focus of this DevRoom is of course the same as the last few years, 
namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel 
  or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management, low level toolkit stuff, and other areas which 
  i might have overlooked above are accepted.

Slots are 50 minutes long, and scheduled hourly. This partly to avoid 
confusion and people running all over the place all the time. As a 
speaker, you do not have to fill your whole hour, gaps are never wasted 
time.

Slots will be handed out on a first come, first serve basis. The best 
slots will go to those who apply the earliest. The amount of slots is 
currently not known yet, but there are only 8 slots available, so act 
quickly.

Talk Submission:


Like the last few years, the pentabarf system will be used for talk 
submission. It is not perfect from a devroom organizer and talk 
submitters usability point-of-view, but the new interface is not fully 
implemented yet, and the fosdem organizers have reverted to the old one 
for this year. It is however workable and it ended up working out 
pretty well these last few years.

https://penta.fosdem.org/submission/FOSDEM16

Remember that FOSDEM is not like XDC, it's not some 50 odd people 
meeting with a sliding schedule which only gets filled out on the last 
day. Upwards of 8000 people are visiting this event, and most of them 
get a printed booklet or use the schedule on the FOSDEM website or an 
app for their phone to figure out what to watch or participate in next. 
So please put some effort in your talk submission and details.

Since this an open source community event, please refrain from turning 
in a talk that is a pure corporate or product commercial. Also, if you 
are unsure on whether you can come or not (this is FOSDEM, why are you 
not there anyway?), please wait with submitting your talk. Submitting a 
talk and then not turning up because you could not be bothered is a 
sure-fire way to get larted and then to never be allowed to talk again.

Also, all talks will be recorded, and will be made available as CC-BY 
after a bit of time. Since we have only a single day devroom, we 
probably will not end up being streamed live.

As for deadlines, the fosdem organizers are doing their booklet 
differently again, and they need to have the schedule finished by the 
18th of december. Given that there are only 8 slots, i trust that this 
will not be an issue this year.

Don't count on this deadline: first come first serve! There are perhaps 
only 8 slots. And the worst slots will be assigned to those who come 
last. Do you really want to talk on sunday at 9:00 when people are still 
in zombie mode after 2 nights at the delirium bar, if they are here at all?

Use your account from last year, so you can try to recycle some of your 
data from last year. If you have forgotten your password, then you can 
reset it here: https://penta.fosdem.org/user/forgot_password

Necessary information:
--

Below is a list of what i need to see filled in when you apply for a 
devroom before i consider it a valid submission. Remember: first come, 
first serve. The best slots are for the earliest submissions and there 
are only 8 slots.

On your personal page:
* General:
  * First and last name
  * Nickname
  * Image
* Contact:
  * email
  * mobile number (this is a very hard requirement as there will be no 
   other reliable form of emergency communication on the day)
* Description:
  * Abstract
  * Description

Create an event:
* On the General page:
  * Event title
  * Event subtitle.
  * Track: Graphics Devroom
  * Event type: Lecture (talk) or Meeting (BoF)
* Persons:
  * Add yourself as speaker.
* Description:
  * Abstract:
  * Full Description
* Links:
  * Add relevant links.

Everything else can be ignored or will be filled in by me or the FOSDEM
organizers. Remember, i will only schedule your talk after the basics 
are somewhat filled in (you still can change them until december 18th).

That's about it. Hope to see you all at FOSDEM :)

Luc Verhaegen.

Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

2015-10-31 Thread Peter Hutterer


On 31/10/2015 09:17 , Bryce Harrington wrote:

On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote:

The frame event groups separate pointer events together. The primary use-case
for this at the moment is diagonal scrolling - a vertical/horizontal scroll
event can be grouped together to calculate the correct motion vector.


If I understand correctly, this is an optimization for non-orthogonal
cursor movement?  Or is there some specialized hardware or usage pattern
that needs this functionality specifically?


any touchpad, more or less :)
if you scroll diagonally, the wayland protocol has no indication that a 
vertical scroll event is followed by a horizontal one (or vice versa) so 
you don't necessarily know when to update the UI.
Think about it this way: there's a reason we send x/y in the same 
pointer event :)


The immediate impact is relatively low.



Frame events group all wl_pointer events. An example sequence of motion events
followed by a diagonal scroll followed by a button event is:
wl_pointer.motion
wl_pointer.frame
wl_pointer.motion
wl_pointer.frame
wl_pointer.axis
wl_pointer.axis
wl_pointer.frame
wl_pointer.button
wl_pointer.frame

In the future, other extensions may insert additional information about an
event into the frame. For example, an extension may add information about the
physical device that generated an event into the frame. For this reason,
enter/leave events are grouped by a frame event too.

The axis_source event determines how an axis event was generated. That enables
clients to judge when to use kinetic scrolling. Only one axis_source event is
allowed per frame and applies to all events in this frame.

The axis_stop event notifies a client about the termination of a scroll
sequence, likewise needed to calculate kinetic scrolling parameters.
Multiple axis_stop events within the same frame indicate that scrolling has
stopped in all these axis at the same time.

The axis_discrete event provides the wheel click count. Previously the axis
value was some hardcoded number (10), with the discrete steps this enables a
client to differ between line-based scrolling on a mouse wheel and smooth
scrolling with a touchpad.

We can't extend the existing wl_pointer.axis events so we introduce a new
concept: latching events.


Could you briefly explain why that can't be extended?


The GNOME guys have a need for knowing a bit more about the device that 
generates a specific event, specifically: was this a touchpad, a mouse, 
a trackball, etc. Based on that the UI may react differently.
This isn't something that should be in the core wayland protocol, but a 
specific extension could add this information as additional events 
inside a frame.



These events (currently only axis_discrete)
are prefixed before a wl_pointer.axis event. A client must build the full
state of the event until the respective top-level event arrives.
i.e. a single event frame for a diagonal scroll with discrete information may
be:

wl_pointer.axis_source
wl_pointer.axis_discrete
wl_pointer.axis
wl_pointer.axis_discrete
wl_pointer.axis
wl_pointer.frame

Signed-off-by: Peter Hutterer 


Is this a new concept unique to Wayland, or has this design been
employed before in X11 or other window systems?  (Sorry, my depth in
input tech is pretty shallow.)  If there is prior art, it might be worth
a h/t.


we have wl_touch.frame for pretty much the same reason - multiple touch 
point updates in the same HW event that should be considered as 
simultaneous.
in the proposed tablet protocol, the wl_tablet.frame event does the same 
- we may get 5 axes updated simultaneously and need to signal that.
The kernel's evdev protocol is another example of serial event stacking 
- you get EV_SYN SYN_REPORT as a signal that the previous events all 
belong together.


X doesn't do this, we pack all the information into a single event, but 
this makes it a lot harder to extend with extra information, especially 
optional information. libinput doesn't do it, but mostly because that is 
a C API where we can add information later and get the same effect. 
wayland is effectively a serialised API, so we need some frame event to 
get to that point.





A few minor copyedits below.


---
Changes to v4:
- axis argument added to axis_discrete. While technically redundant since
   the axis event carries this information, the lack of this argument leads
   to awkward client-side implementation. A single uint32_t value with no
   other information attached had to be stacked in a temporary variable, only
   the next event can then tell us whether the event was x or y scroll.
   Providing the axis in the discrete event means we can immediately stack
   this into the right variable.
- the big change is the rename from axis_frame to wl_pointer.frame.
   the axis_frame concept was solid but working on other things Carlos and I
   discovered that we may need to add additional information to some events.
   A generic

[PATCH weston v2] drm: port the drm backend to the new init api

[PATCH weston v3] drm: port the drm backend to the new init api

FOSDEM16: Graphics DevRoom: call for speakers.

Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

4 matches

Site Navigation

Mail list logo

Footer information