Re: Trying to understand how to show a surface
On 04/19/2013 04:57 AM, João Jerónimo wrote:
Em 19-04-2013 01:52, dar...@chaosreigns.com escreveu:
Might be useful to post the code.
Ok. I'll post it then.
I'm linking only the wayland libraries. One also needs to use the
-std=gnu++11 flag.
[...]
int main()
{
try {
printf(Hello world! Example Wayland client...\n);
// Connect
[...]
wl_display_dispatch(display);
wl_display_roundtrip(display);
cout End of globals... endl endl;
// Create surface
[...]
for (int i=0; i100*200; ++i) {
buffer[i] = 0x40404040;
}
wl_surface_attach(surface, buffer_wl, 0, 0);
wl_surface_damage(surface, 0, 0, 100, 200);
wl_surface_commit(surface);
for(;;);
When the program enters the infinite loop, the requests are still
sitting in the connection buffer in the client side. Before blocking,
clients should call wl_display_flush(). You'll find more details in the
Wayland client API documentation:
http://wayland.freedesktop.org/docs/html/chap-Library.html#sect-Library-Client
Cheers,
Ander
// Terminate connection
wl_display_disconnect(display);
return 0;
}
catch(string errstr) {
cout FATAL: errstr endl;
}
}
João Jerónimo
On 04/19, João Jerónimo wrote:
Hello.
I was trying to understand what is the minimal code needed to get a
square painter on the screen. However, although I can make the
client talk to the Weston compositor, enumerate the global objects,
etc, I can't still see my surface drawn in the compositor scene.
The steps that my program makes so far are as follows:
- call wl_display_connect(NULL)
- call wl_display_get_registry(display)
- Install listeners for the registry that wl_registry_bind() many
of the advertised objects. However, I'm not listening to the events
of the objects advertised by the registry. Is it needed?
- call wl_display_dispatch() and wl_display_roundtrip()
- call wl_compositor_create_surface()
- mkostemp() a file and ftruncate() it to some 10MB or so
- mmap() the entire file created
- call wl_shm_create_pool()
- call wl_shm_pool_create_buffer()
- call wl_display_dispatch()
- Fill the buffer with some content. I filled it entirely with
pattern 0x40404040.
- call wl_surface_attach(surface, buffer, 0, 0)
- Then the program just sits in an infinite loop...
Am I missing anything?
Sorry for my poor English (assuming that you think it's poor)
João Jerónimo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Input and games.
Hi Todd, I am going to reply from the Wayland protocol point of view, and what Wayland explicitly can (and must) do for you. This is likely much lower level than what a game programmer would like to use. How SDL or some other higher level library exposes input is a different matter, and I will not comment on that. We just want to make everything possible on the Wayland protocol level. On Thu, 18 Apr 2013 18:22:11 -0400 Todd Showalter t...@electronjump.com wrote: On Thu, Apr 18, 2013 at 5:29 PM, Jonas Kulla nyocu...@gmail.com wrote: What exactly do you mean by unique requirements, can you be a little bit more specific? In general I think the current consensus (correct me if I'm wrong) is that using the default wayland pointer and keyboard events plus Joypad support via SDL is sufficient for most purposes. In general we can work with anything as long as we can get the right events and process them; it's perhaps more a matter of convenience. There are a few things of note that are somewhat specific to games: Permissions We're often running things like mods, user-generated scripts, and in general lots of untrusted content, so the fewer privileges we need to handle things like input, the better. I do not think we can happily let client applications open input devices themselves, so this is clearly a thing we need to improve on. In other words, I believe we should come up with a protocol extension where the server opens the input devices, and either passes the file descriptor to a client, or the server translates evdev events into Wayland protocol events. How and what are still open questions, as is every other detail of input devices that are not keyboards, mice, or touchscreens. There was once some talk about raw input event protocol, but there is not even a sketch of it, AFAIK. Hooking Things Up This may be beyond the scope of Wayland, but at least in the past I've found that in particular joysticks/gamepads are a bit of a guessing game for the developer. You can usually assume that the first stick is the first couple of axis values in the axis array, but after that, it's a tossup whether an analog axis is part of a stick a trigger, or a pressure-sensitive button. It would be really nice if there was some sort of configuration that could be read so we'd know how the player wanted these things mapped, and some sort of way for the player to set that configuration up outside the game. Right, and whether this could be a Wayland thing or not, depends on the above, how to handle misc input devices in general. Keyboards already have extensive mapping capabilities. A Wayland server sends keycodes (I forget in which space exactly) and a keymap, and clients feed the keymap and keycodes into libxkbcommon, which translates them into something actually useful. Maybe something similar could be invented for game controllers? But yes, this is off-topic for Wayland, apart from the protocol of what event codes and other data to pass. Event Driven vs. Polling Modern gui applications tend to be event-driven, which makes sense; most modern desktop applications spend most of their time doing nothing and waiting for the user to generate input. Games are different, in that they tend to be simulation-based, and things are happening regardless of whether the player is providing input. In most games, you have to poll input between simulation ticks. If you accept and process an input event in the middle of a simulation tick, your simulation will likely be internally inconsistent. Input in games typically moves or changes in-game objects, and if input affects an object mid-update, part of the simulation tick will have been calculated based on the old state of the object, and the rest will be based on the new state. To deal with this on event-driven systems, games must either directly poll the input system, or else accumulate events and process them between simulation ticks. Either works, but being able to poll means the game needs to do less work. Wayland protocol in event driven. Polling does not make sense, since it would mean a synchronous round-trip to the server, which for something like this is just far too expensive, and easily (IMHO) worked around. So, you have to maintain input state yourself, or by a library you use. It could even be off-loaded to another thread. There is also a huge advantage over polling: in an event driven design, it is impossible to miss very fast, transient actions, which polling would never notice. And whether you need to know if such a transient happened, or how many times is happened, or how long time each transient took between two game ticks, is all up to you and available. I once heard about some hardcore gamer complaining, that in some systems or under some conditions, probably related to the ridiculous framerates gamers usually demand, the button sequence he hits in a fraction of
Add simple EDID parsing to Weston
At the moment weston doesn't know anything about EDID blobs. To make the CMS functionality complete we have to tell the CM the display attributes, e.g. make, model and serial. This allows us to show something nice in the calibration UI, and also allows us to match a specific _display_ to the color profile, not just the _output_ that it's sitting on. Getting the serial is important as there might be more than one monitor of the same type attached which is quite common. I've attached 3 patches for initial review. They don't depend on my CMS patchset to not block one on the other. They probably need detailed review for correctness/coding style as this is code ported from GNOME. Comments welcome, thanks. Richard 0001-Extract-the-EDID-blob-when-adding-a-DRM-output.patch Description: Binary data 0002-Add-a-serial-property-on-weston_output.patch Description: Binary data 0003-Parse-the-EDID-when-outputs-are-added.patch Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] Extract the EDID blob when adding a DRM output
---
src/compositor-drm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..61ef97e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -139,6 +139,7 @@ struct drm_output {
int pipe;
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
+ drmModePropertyBlobPtr edid_blob;
int vblank_pending;
int page_flip_pending;
@@ -1011,6 +1012,9 @@ drm_output_destroy(struct weston_output *output_base)
(struct drm_compositor *) output-base.compositor;
drmModeCrtcPtr origcrtc = output-original_crtc;
+ if (output-edid_blob)
+ drmModeFreePropertyBlob(output-edid_blob);
+
if (output-backlight)
backlight_destroy(output-backlight);
@@ -1499,6 +1503,7 @@ create_output_for_connector(struct drm_compositor *ec,
drmModeEncoder *encoder;
drmModeModeInfo crtc_mode;
drmModeCrtc *crtc;
+ drmModePropertyPtr property;
int i;
char name[32];
const char *type_name;
@@ -1642,6 +1647,27 @@ create_output_for_connector(struct drm_compositor *ec,
wl_list_insert(ec-base.output_list.prev, output-base.link);
+ /* find the EDID blob */
+ for (i = 0; i connector-count_props !output-edid_blob; i++) {
+ property = drmModeGetProperty(ec-drm.fd, connector-props[i]);
+ if (!property)
+ continue;
+ if ((property-flags DRM_MODE_PROP_BLOB)
+ !strcmp(property-name, EDID)) {
+ output-edid_blob = drmModeGetPropertyBlob(ec-drm.fd,
+
connector-prop_values[i]);
+ }
+ drmModeFreeProperty(property);
+ }
+
+ /* parse the EDID blob */
+ if (output-edid_blob) {
+ weston_log(Got EDID blob %p of size %u.\n,
+ output-edid_blob-data,
+ output-edid_blob-length);
+ /* FIXME: actually parse EDID */
+ }
+
output-base.origin = output-base.current;
output-base.start_repaint_loop = drm_output_start_repaint_loop;
output-base.repaint = drm_output_repaint;
--
1.8.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/3] Add a 'serial' property on weston_output
---
src/compositor-drm.c | 1 +
src/compositor.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 61ef97e..a454676 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1522,6 +1522,7 @@ create_output_for_connector(struct drm_compositor *ec,
output-base.subpixel = drm_subpixel_to_wayland(connector-subpixel);
output-base.make = unknown;
output-base.model = unknown;
+ output-base.serial = unknown;
wl_list_init(output-base.mode_list);
if (connector-connector_type ARRAY_LENGTH(connector_type_names))
diff --git a/src/compositor.h b/src/compositor.h
index 1e999a6..fa6162c 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -178,7 +178,7 @@ struct weston_output {
uint32_t frame_time;
int disable_planes;
- char *make, *model;
+ char *make, *model, *serial;
uint32_t subpixel;
uint32_t transform;
--
1.8.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] Parse the EDID when outputs are added
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 166 ++-
1 file changed, 165 insertions(+), 1 deletion(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index a454676..4f37447 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -25,6 +25,7 @@
#include errno.h
#include stdlib.h
+#include ctype.h
#include string.h
#include fcntl.h
#include unistd.h
@@ -131,6 +132,14 @@ struct drm_fb {
void *map;
};
+struct drm_edid {
+ char *monitor_name;
+ char *serial_number;
+ char *eisa_id;
+ char *pnp_id;
+ /* other things can be added as required */
+};
+
struct drm_output {
struct weston_output base;
@@ -140,6 +149,7 @@ struct drm_output {
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
drmModePropertyBlobPtr edid_blob;
+ struct drm_edid *edid;
int vblank_pending;
int page_flip_pending;
@@ -1005,6 +1015,16 @@ static void
drm_output_fini_pixman(struct drm_output *output);
static void
+drm_edid_destroy(struct drm_edid *edid)
+{
+ free(edid-monitor_name);
+ free(edid-serial_number);
+ free(edid-eisa_id);
+ free(edid-pnp_id);
+ free(edid);
+}
+
+static void
drm_output_destroy(struct weston_output *output_base)
{
struct drm_output *output = (struct drm_output *) output_base;
@@ -1014,6 +1034,8 @@ drm_output_destroy(struct weston_output *output_base)
if (output-edid_blob)
drmModeFreePropertyBlob(output-edid_blob);
+ if (output-edid)
+ drm_edid_destroy (output-edid);
if (output-backlight)
backlight_destroy(output-backlight);
@@ -1490,6 +1512,131 @@ drm_output_fini_pixman(struct drm_output *output)
}
}
+static char *
+edid_parse_string (const uint8_t *data)
+{
+ char *text;
+ int i;
+ int replaced = 0;
+
+ /* this is always 12 bytes, but we can't guarantee it's null
+* terminated or not junk. */
+ text = strndup ((const char *) data, 12);
+
+ /* remove insane chars */
+ for (i = 0; text[i] != '\0'; i++) {
+ if (text[i] == '\n' ||
+ text[i] == '\r')
+ text[i] = '\0';
+ }
+
+ /* nothing left? */
+ if (text[0] == '\0') {
+ free (text);
+ text = NULL;
+ goto out;
+ }
+
+ /* ensure string is printable */
+ for (i = 0; text[i] != '\0'; i++) {
+ if (!isprint (text[i])) {
+ text[i] = '-';
+ replaced++;
+ }
+ }
+
+ /* if the string is random junk, ignore the string */
+ if (replaced 4) {
+ free (text);
+ text = NULL;
+ goto out;
+ }
+out:
+ return text;
+}
+
+#define EDID_DESCRIPTOR_ALPHANUMERIC_DATA_STRING 0xfe
+#define EDID_DESCRIPTOR_DISPLAY_PRODUCT_NAME 0xfc
+#define EDID_DESCRIPTOR_DISPLAY_PRODUCT_SERIAL_NUMBER 0xff
+#define EDID_OFFSET_DATA_BLOCKS0x36
+#define EDID_OFFSET_LAST_BLOCK 0x6c
+#define EDID_OFFSET_PNPID 0x08
+#define EDID_OFFSET_SERIAL 0x0c
+
+static int
+edid_parse (struct drm_edid *edid, const uint8_t *data, size_t length)
+{
+ char *tmp;
+ int i;
+ int rc = 0;
+ uint32_t serial;
+
+ /* check header */
+ if (length 128) {
+ rc = -1;
+ goto out;
+ }
+ if (data[0] != 0x00 || data[1] != 0xff) {
+ rc = -1;
+ goto out;
+ }
+
+ /* decode the PNP ID from three 5 bit words packed into 2 bytes
+* /--08--\/--09--\
+* 7654321076543210
+* |\---/\---/\---/
+* R C1 C2 C3 */
+ edid-pnp_id = malloc(4);
+ edid-pnp_id[0] = 'A' + ((data[EDID_OFFSET_PNPID+0] 0x7c) / 4) - 1;
+ edid-pnp_id[1] = 'A' + ((data[EDID_OFFSET_PNPID+0] 0x3) * 8) +
((data[EDID_OFFSET_PNPID+1] 0xe0) / 32) - 1;
+ edid-pnp_id[2] = 'A' + (data[EDID_OFFSET_PNPID+1] 0x1f) - 1;
+ edid-pnp_id[3] = '\0';;
+
+ /* maybe there isn't a ASCII serial number descriptor, so use this
instead */
+ serial = (int32_t) data[EDID_OFFSET_SERIAL+0];
+ serial += (int32_t) data[EDID_OFFSET_SERIAL+1] * 0x100;
+ serial += (int32_t) data[EDID_OFFSET_SERIAL+2] * 0x1;
+ serial += (int32_t) data[EDID_OFFSET_SERIAL+3] * 0x100;
+ if (serial 0) {
+ edid-serial_number = malloc(9);
+ sprintf (edid-serial_number, %li, (long int) serial);
+ }
+
+ /* parse EDID data */
+ for
Re: Input and games.
On Fri, Apr 19, 2013 at 5:18 AM, Pekka Paalanen ppaala...@gmail.com wrote: I am going to reply from the Wayland protocol point of view, and what Wayland explicitly can (and must) do for you. This is likely much lower level than what a game programmer would like to use. How SDL or some other higher level library exposes input is a different matter, and I will not comment on that. We just want to make everything possible on the Wayland protocol level. That's fair. We don't use SDL in our projects, so I'm coming at this partly from the point of view of someone who will be operating at the protocol level. I do not think we can happily let client applications open input devices themselves, so this is clearly a thing we need to improve on. In other words, I believe we should come up with a protocol extension where the server opens the input devices, and either passes the file descriptor to a client, or the server translates evdev events into Wayland protocol events. How and what are still open questions, as is every other detail of input devices that are not keyboards, mice, or touchscreens. This is certainly what I'd prefer, personally, whether it's a file-descriptor based system, event messaging, or polling functions. It would be really nice to get gamepads and the like in there, if possible. There was once some talk about raw input event protocol, but there is not even a sketch of it, AFAIK. I'm not familiar enough with Wayland yet to take the lead on something like that, but I can certainly help. It would be really nice if there was some sort of configuration that could be read so we'd know how the player wanted these things mapped, and some sort of way for the player to set that configuration up outside the game. Right, and whether this could be a Wayland thing or not, depends on the above, how to handle misc input devices in general. Keyboards already have extensive mapping capabilities. A Wayland server sends keycodes (I forget in which space exactly) and a keymap, and clients feed the keymap and keycodes into libxkbcommon, which translates them into something actually useful. Maybe something similar could be invented for game controllers? But yes, this is off-topic for Wayland, apart from the protocol of what event codes and other data to pass. Fair enough. Wayland protocol in event driven. Polling does not make sense, since it would mean a synchronous round-trip to the server, which for something like this is just far too expensive, and easily (IMHO) worked around. So, you have to maintain input state yourself, or by a library you use. It could even be off-loaded to another thread. This is what we do now, essentially; accumulate the incoming events to assemble each frame's input device state. It would be convenient if Wayland did it for us, but obviously we're already operating this way on X11, Win32 and OSX. There is also a huge advantage over polling: in an event driven design, it is impossible to miss very fast, transient actions, which polling would never notice. And whether you need to know if such a transient happened, or how many times is happened, or how long time each transient took between two game ticks, is all up to you and available. In truth, we don't usually deal with pure polling at the low level unless it's a game where we can guarantee that we're not going to drop frames. Even then, things like mouse, touch or stylus input can come in way faster than vsync, and game simulation ticks are usually (for relatively obvious reasons) timed to vsyncs. In our engine, the input system has several parts, collected in a per-player virtualized input structure. It contains: - analog axis - previous position - current position - delta (current - prev) - array of positions used to generate this frame's data - buttons - previous frame state bitmap (1 bit per key/button) - current frame state bitmap - trigger bitmap (cur ~prev) - release bitmap (prev ~cur) - byte map of presses If a key/button event was received since the last update, that key or button is left down for at least one update, even if it went up again before the snapshot went out. If the game cares how many times a button or key was pressed between updates, it can look the key up in the byte map rather than the bitmap. Likewise, while accumulated position/delta is usually good enough for mouse/touch/stylus input and almost always good enough for joystick input, there are times when you want to do things like gesture recognition where it really pays to have the data at the finest possible resolution. Most parts of the game won't care, but the data is there if it's needed. I once heard about some hardcore gamer complaining, that in some systems or under some conditions, probably related to the ridiculous framerates gamers usually demand, the button sequence he hits in a fraction of a second is not registered
RE: Seats support
If this is the case (two different output, two different seats), then why not have two different compositors? Perhaps you need some syncing between them? Is there something else I'm missing here? I don't know for sure, but It should be possible (perhaps with a little modification) to have two simultaneous weston sessions running. I don't think that's supported yet, but it may not take much. Both views can have surfaces moving around between them and you can even have a case where a surface is split half and half in between the two views. While all this could be achieved through two compositor instances, it would be a whole lot simpler if just one compositor managed both with a seat per output. I have implemented the latter and it was relatively trivial. -Satyeshwar -Original Message- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, April 18, 2013 11:47 PM To: Singh, Satyeshwar Cc: Jason Ekstrand; wayland-devel@lists.freedesktop.org; Andrew Voron Subject: Re: Seats support On Thu, 18 Apr 2013 19:36:55 -0500 Jason Ekstrand ja...@jlekstrand.net wrote: Singh, On Thu, Apr 18, 2013 at 12:35 PM, Singh, Satyeshwar satyeshwar.si...@intel.com wrote: Hi Jason, As of right now, weston doesn't have a way (as far as I know) to split your devices into multiple seats. Then again, I don't really see why you would want to unless you plan to have two people working on the same computer simultaneously (I guess that's a possibility). In a car, where the real estate is limited, there is only one monitor but dual view (so that the driver sees one content and the front seat passenger sees another). They both have their own trackpads and this requires two input devices to be routed to two different Wayland outputs (each view is a wl_output) and can simultaneously control their own view. If this is the case (two different output, two different seats), then why not have two different compositors? Perhaps you need some syncing between them? Is there something else I'm missing here? I don't know for sure, but It should be possible (perhaps with a little modification) to have two simultaneous weston sessions running. I don't think that's supported yet, but it may not take much. Indeed, maybe this comes from the confusion, that wl_seat is not a seat. wl_seat is a collection of input devices, and provides at most one pointer, one keyboard, etc. to clients. This may be best thought via foci: there is only one keyboard focus for a wl_seat. This is a just a protocol abstraction. A seat comprising of a display and a keyboard (in the classical setup), like a literal console seat with a chair, table, monitor, keyboard etc., is not a wl_seat. These physical seats are more like separate compositor instances, since you usually have different users logged in, and the desktop is not shared between them. In other words, they are separate sessions. So the car example would really be two (session) compositor instances, not two wl_seats. And I think the evdev based backends of Weston are using udev tags or something to pick and choose which input devices to open, so for Weston you give a seat label, and then all input devices with that label get opened. Input device labeling happens in udev. I believe currently all input devices opened are added to one wl_seat, but that's just a Weston detail. Thanks, pq -Original Message- From: wayland-devel-bounces+satyeshwar.singh= intel@lists.freedesktop.org [mailto: wayland-devel-bounces+satyeshwar.singh=intel@lists.freedesktop.org] On Behalf Of Jason Ekstrand Sent: Wednesday, April 17, 2013 1:49 PM To: Andrew Voron Cc: wayland-devel@lists.freedesktop.org Subject: Re: Seats support Andrew, The seat concept is meant for each seat to correspond to one human interface to the desktop. For example, say you have a fancy laptop with a touchscreen as well as both a trackpad and a nub. And let's say that we further complicate the situation by plugging in an external keyboard/mouse. All of those devices would be one one seat. The wl_pointer would be an agrigate from all three pointing devices and the wl_keyboard would get key events from both keyboards. the wl_touch would just be the one touch screen in this case. As of right now, weston doesn't have a way (as far as I know) to split your devices into multiple seats. Then again, I don't really see why you would want to unless you plan to have two people working on the same computer simultaneously (I guess that's a possibility). The only back-end that currently provides multiple seats is Hardening's RDP back-end that provides one seat for each connected RDP client. I hope that helps, --Jason Ekstrand On Wed, Apr 17, 2013 at 3:26 AM, Andrew Voron volan...@gmail.com wrote: Hello. I want to clarify a seats supporting by wayland(and weston). By seats support I mean an
Re: [PATCH 1/3] Extract the EDID blob when adding a DRM output
Hi
On Fri, Apr 19, 2013 at 5:02 PM, Richard Hughes hughsi...@gmail.com wrote:
---
src/compositor-drm.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..61ef97e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -139,6 +139,7 @@ struct drm_output {
int pipe;
uint32_t connector_id;
drmModeCrtcPtr original_crtc;
+ drmModePropertyBlobPtr edid_blob;
int vblank_pending;
int page_flip_pending;
@@ -1011,6 +1012,9 @@ drm_output_destroy(struct weston_output *output_base)
(struct drm_compositor *) output-base.compositor;
drmModeCrtcPtr origcrtc = output-original_crtc;
+ if (output-edid_blob)
+ drmModeFreePropertyBlob(output-edid_blob);
+
Why do you keep the blob around all the time? Just free it in
create_output_for_connector() after you parsed it. If we somehow need
it later, we can always change it again. But your patches don't depend
on it being around all the time so lets just free it right away.
if (output-backlight)
backlight_destroy(output-backlight);
@@ -1499,6 +1503,7 @@ create_output_for_connector(struct drm_compositor *ec,
drmModeEncoder *encoder;
drmModeModeInfo crtc_mode;
drmModeCrtc *crtc;
+ drmModePropertyPtr property;
We use drmXY * instead of drmXYPtr here, so lets be consistent.
int i;
char name[32];
const char *type_name;
@@ -1642,6 +1647,27 @@ create_output_for_connector(struct drm_compositor *ec,
wl_list_insert(ec-base.output_list.prev, output-base.link);
+ /* find the EDID blob */
+ for (i = 0; i connector-count_props !output-edid_blob; i++) {
+ property = drmModeGetProperty(ec-drm.fd,
connector-props[i]);
+ if (!property)
+ continue;
+ if ((property-flags DRM_MODE_PROP_BLOB)
+ !strcmp(property-name, EDID)) {
+ output-edid_blob = drmModeGetPropertyBlob(ec-drm.fd,
+
connector-prop_values[i]);
+ }
+ drmModeFreeProperty(property);
+ }
+
+ /* parse the EDID blob */
+ if (output-edid_blob) {
+ weston_log(Got EDID blob %p of size %u.\n,
+ output-edid_blob-data,
+ output-edid_blob-length);
+ /* FIXME: actually parse EDID */
+ }
+
output-base.origin = output-base.current;
output-base.start_repaint_loop = drm_output_start_repaint_loop;
output-base.repaint = drm_output_repaint;
Regards
David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Override modules list and don't always load desktop-shell.so
2013/4/16 Kristian Høgsberg hoegsb...@gmail.com: On Sun, Apr 14, 2013 at 07:17:40PM +0200, Pier Luigi Fiorini wrote: Let --modules override modules list and load desktop-shell.so as a fallback if a modules list is not specified neither by passing --modules nor with weston.ini. Signed-off-by: Pier Luigi Fiorini pierluigi.fior...@gmail.com --- man/weston.man | 5 +++-- src/compositor.c | 7 +++ 2 files changed, 6 insertions(+), 6 deletions(-) I know the current behavior is a bit problematic for some use cases. However it works well for the case where you load a plugin in addition to the shell, like xwayland. I'm not sure what the best way to make both cases work is, except to make the shell plugin special. We could go back to use a shell config key and command line option and make modules only about additional modules. Kristian Seems the best approach to me, you are supposed to use only one shell and you might load multiple plugins and this make the shell plugin somehow special to me. -- Out of the box experience http://www.maui-project.org/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Input and games.
Todd Showalter wrote: On Fri, Apr 19, 2013 at 1:52 PM, Jonas Kulla nyocu...@gmail.com wrote: I'm stuck on a Mac at the moment, unfortunately, so I can't give you verified Linux examples, but I'm writing this email in the GMail web client on Firefox. If I grab the scroll thumb and drag it upwards, the mouse pointer moves far more slowly than if I just moved the mouse up without grabbing the thumb... I have seen this before too, on Windows software. I think this is going to require pointer warping. At first I thought it could be done by hiding the pointer and faking it's position, but that would not stop the invisible pointer from moving out of the window and becoming visible, or moving into a hot-spot and triggering an unexpected effect. Also, I'm pretty sure something like mouse warping will likely never be implemented in wayland for design reasons (you don't want malicious apps controlling crucial variables such as pointer location). This can be avoided by not allowing you to warp the pointer unless you have the seat focus. You may even require the pointer focus, though I think there are useful schemes where the client that has keyboard focus can move the related pointer). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Override modules list and don't always load desktop-shell.so
2013/4/16 Kristian Høgsberg hoegsb...@gmail.com: I know the current behavior is a bit problematic for some use cases. However it works well for the case where you load a plugin in addition to the shell, like xwayland. I'm not sure what the best way to make both cases work is, except to make the shell plugin special. We could go back to use a shell config key and command line option and make modules only about additional modules. Would it be possible to load all the named modules, then find out if any of them are shells, and load the default shell if none are? Ie if the command line does not name a shell module you will get the default one. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
