[PATCH] edid: Add quirk for ADA 1024x600 7" display.
Detailed mode reports 108 mm x 68 mm which is for smaller display. Maximum image size reports 15 cm x 10 cm which aligns with its physical size, use this size instead. Signed-off-by: Kai-Heng Feng --- hw/xfree86/modes/xf86EdidModes.c | 5 + 1 file changed, 5 insertions(+) diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c index f24294e..f0e1e97 100644 --- a/hw/xfree86/modes/xf86EdidModes.c +++ b/hw/xfree86/modes/xf86EdidModes.c @@ -153,6 +153,11 @@ quirk_detailed_v_in_cm(int scrnIndex, xf86MonPtr DDC) static Bool quirk_detailed_use_maximum_size(int scrnIndex, xf86MonPtr DDC) { +/* ADA 1024x600 7" display */ +if (memcmp(DDC->vendor.name, "ADA", 4) == 0 && +DDC->vendor.prod_id == 4) +return TRUE; + /* Bug #21324: Iiyama Vision Master 450 */ if (memcmp(DDC->vendor.name, "IVM", 4) == 0 && DDC->vendor.prod_id == 6400) return TRUE; -- 2.10.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [qxl] xspice: Adjust to X.org 1.19 changes
On Wed, Dec 14, 2016 at 12:07:55PM +0100, Hans de Goede wrote: > Hi, > > On 14-12-16 11:51, Christophe Fergeau wrote: > > In newer X.org versions, it's no longer supported to modify the set of > > FDs passed to a BlockHandler method to get notified when the FD has data > > to be read. This was limited anyway as we could only get read events > > this way, and had to do our own polling to get notified about socket > > writeability. > > > > Starting from xserver 1.19, the supported way of doing this is to use > > the SetNotifyFd/RemoveNotifyFd API, which is actually a much better way > > as it matches very well the 'watch' API spice-server expects Xspice to > > implement. > > > > This commit switches to that new API, which removes the need for > > RegisterBlockAndWakeupHandlers(). > > Thank you for doing this, one small comment inline, otherwise looks > good: > > Reviewed-by: Hans de Goede I had a small unapplied change in my working copy, s/watch_update_mask2/watch_update_mask_internal/ which I squashed in. > > +static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, > > void *opaque) > > +{ > > +SpiceWatch *watch = malloc(sizeof(SpiceWatch)); > > This malloc may fail, please replace malloc with > xnfalloc which stands for X no fail alloc, it works like > the glib malloc functions. There are several other occurrences of unchecked malloc in the Xspice code, as well as a few strdup calls. I'll change these in a follow-up patch. Christophe signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes
Hi Christophe, Please see some comments below On 12/14/2016 12:51 PM, Christophe Fergeau wrote: In newer X.org versions, it's no longer supported to modify the set of FDs passed to a BlockHandler method to get notified when the FD has data to be read. This was limited anyway as we could only get read events this way, and had to do our own polling to get notified about socket writeability. Starting from xserver 1.19, the supported way of doing this is to use the SetNotifyFd/RemoveNotifyFd API, which is actually a much better way as it matches very well the 'watch' API spice-server expects Xspice to implement. This commit switches to that new API, which removes the need for RegisterBlockAndWakeupHandlers(). --- I've lightly (xeyes/rxvt) tested this on f25, and tested this still builds on f24. This should fix the issues Hans mentioned in https://lists.freedesktop.org/archives/spice-devel/2016-October/032501.html configure.ac | 5 --- src/spiceqxl_main_loop.c | 90 2 files changed, 84 insertions(+), 11 deletions(-) [skip] diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c index 49b715a..81bc418 100644 --- a/src/spiceqxl_main_loop.c +++ b/src/spiceqxl_main_loop.c [skip] @@ -276,7 +272,7 @@ static void xspice_block_handler(pointer data, OSTimePtr timeout, pointer readma /* * xserver only calls wakeup_handler with the read fd_set, so we * must either patch it or do a polling select ourselves, this is the - * later approach. Since we are already doing a polling select, we + * latter approach. Since we are already doing a polling select, we * already select on all (we could avoid selecting on the read since * that *is* actually taken care of by the wakeup handler). */ @@ -338,9 +334,88 @@ static void xspice_wakeup_handler(pointer data, int nfds, pointer readmask) select_and_check_watches(); } +#else /* GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23 */ + +struct SpiceWatch { +int fd; +int event_mask; +SpiceWatchFunc func; +void *opaque; +}; + +static void watch_fd_notified(int fd, int xevents, void *data) +{ +SpiceWatch *watch = (SpiceWatch *)data; + +if ((watch->event_mask & SPICE_WATCH_EVENT_READ) && (xevents & X_NOTIFY_READ)) { +watch->func(watch->fd, SPICE_WATCH_EVENT_READ, watch->opaque); +} + +if ((watch->event_mask & SPICE_WATCH_EVENT_WRITE) && (xevents & X_NOTIFY_WRITE)) { +watch->func(watch->fd, SPICE_WATCH_EVENT_WRITE, watch->opaque); +} +} + +static int watch_update_mask2(SpiceWatch *watch, int event_mask) +{ +SetNotifyFd(watch->fd, NULL, X_NOTIFY_NONE, NULL); +watch->event_mask = 0; + +if (event_mask & SPICE_WATCH_EVENT_READ) { +SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_READ, watch); +} else if (event_mask & SPICE_WATCH_EVENT_READ) { 1. This should be (event_mask & SPICE_WATCH_EVENT_WRITE) 2. The "else if" fails to support event_mask which is READ | WRITE. Can it not watch both events ? Regards, Uri. +SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_WRITE, watch); +} else { +DPRINTF(0, "Unexpected watch event_mask: %i", event_mask); +return -1; +} +watch->event_mask = event_mask; + +return 0; +} + +static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void *opaque) +{ +SpiceWatch *watch = malloc(sizeof(SpiceWatch)); + +DPRINTF(0, "adding %p, fd=%d", watch, fd); + +watch->fd = fd; +watch->func = func; +watch->opaque = opaque; +if (watch_update_mask2(watch, event_mask) != 0) { +free(watch); +return NULL; +} + +return watch; +} + +static void watch_update_mask(SpiceWatch *watch, int event_mask) +{ +DPRINTF(0, "fd %d to %d", watch->fd, event_mask); +watch_update_mask2(watch, event_mask); +} + +static void watch_remove(SpiceWatch *watch) +{ +DPRINTF(0, "remove %p (fd %d)", watch, watch->fd); +RemoveNotifyFd(watch->fd); +free(watch); +} +#endif + +static void channel_event(int event, SpiceChannelEventInfo *info) +{ +NOT_IMPLEMENTED +} + + SpiceCoreInterface *basic_event_loop_init(void) { +#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23 ring_init(&watches); +#endif bzero(&core, sizeof(core)); core.base.major_version = SPICE_INTERFACE_CORE_MAJOR; core.base.minor_version = SPICE_INTERFACE_CORE_MINOR; // anything less then 3 and channel_event isn't called @@ -355,7 +430,10 @@ SpiceCoreInterface *basic_event_loop_init(void) return &core; } + void xspice_register_handlers(void) { +#if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 23 RegisterBlockAndWakeupHandlers(xspice_block_handler, xspice_wakeup_handler, 0); +#endif } ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Spice-devel] [qxl] xspice: Adjust to X.org 1.19 changes
On Thu, Dec 15, 2016 at 02:01:03PM +0200, Uri Lublin wrote: > Hi Christophe, > > Please see some comments below > > On 12/14/2016 12:51 PM, Christophe Fergeau wrote: > > +static int watch_update_mask2(SpiceWatch *watch, int event_mask) > > +{ > > +SetNotifyFd(watch->fd, NULL, X_NOTIFY_NONE, NULL); > > +watch->event_mask = 0; > > + > > +if (event_mask & SPICE_WATCH_EVENT_READ) { > > +SetNotifyFd(watch->fd, watch_fd_notified, X_NOTIFY_READ, watch); > > +} else if (event_mask & SPICE_WATCH_EVENT_READ) { > > 1. This should be (event_mask & SPICE_WATCH_EVENT_WRITE) Oops, good catch! > 2. The "else if" fails to support event_mask which is READ | WRITE. >Can it not watch both events ? For some reason, I think I decided this was not needed, but I can't see why now. I'll update the code. Christophe signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup
spiceqxl_*.c files are Xspice-only code. They contain a few uses of malloc/strdup, and none of these are checked for failure. It's better to replace these with xfnalloc/xnfstrdup which are provided by the X server and cannot fail (aborts on failure). Signed-off-by: Christophe Fergeau --- src/spiceqxl_audio.c| 2 +- src/spiceqxl_main_loop.c| 4 ++-- src/spiceqxl_spice_server.c | 12 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/spiceqxl_audio.c b/src/spiceqxl_audio.c index 52a45f0..ec9260d 100644 --- a/src/spiceqxl_audio.c +++ b/src/spiceqxl_audio.c @@ -405,7 +405,7 @@ static void handle_one_change(qxl_screen_t *qxl, struct inotify_event *e) return; } -fname = malloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 1); +fname = xnfalloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 1); strcpy(fname, qxl->playback_fifo_dir); strcat(fname, "/"); strcat(fname, e->name); diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c index c9894bb..669e116 100644 --- a/src/spiceqxl_main_loop.c +++ b/src/spiceqxl_main_loop.c @@ -209,7 +209,7 @@ int watch_count = 0; static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void *opaque) { -SpiceWatch *watch = malloc(sizeof(SpiceWatch)); +SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch)); DPRINTF(0, "adding %p, fd=%d at %d", watch, fd, watch_count); @@ -376,7 +376,7 @@ static int watch_update_mask_internal(SpiceWatch *watch, int event_mask) static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void *opaque) { -SpiceWatch *watch = malloc(sizeof(SpiceWatch)); +SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch)); DPRINTF(0, "adding %p, fd=%d", watch, fd); diff --git a/src/spiceqxl_spice_server.c b/src/spiceqxl_spice_server.c index 6e8cf50..38257d0 100644 --- a/src/spiceqxl_spice_server.c +++ b/src/spiceqxl_spice_server.c @@ -200,23 +200,23 @@ void xspice_set_spice_server_options(OptionInfoPtr options) len = strlen(x509_dir) + 32; if (x509_key_file_base) { -x509_key_file = strdup(x509_key_file_base); +x509_key_file = xnfstrdup(x509_key_file_base); } else { -x509_key_file = malloc(len); +x509_key_file = xnfalloc(len); snprintf(x509_key_file, len, "%s/%s", x509_dir, X509_SERVER_KEY_FILE); } if (x509_cert_file_base) { -x509_cert_file = strdup(x509_cert_file_base); +x509_cert_file = xnfstrdup(x509_cert_file_base); } else { -x509_cert_file = malloc(len); +x509_cert_file = xnfalloc(len); snprintf(x509_cert_file, len, "%s/%s", x509_dir, X509_SERVER_CERT_FILE); } if (x509_cacert_file_base) { -x509_cacert_file = strdup(x509_cert_file_base); +x509_cacert_file = xnfstrdup(x509_cert_file_base); } else { -x509_cacert_file = malloc(len); +x509_cacert_file = xnfalloc(len); snprintf(x509_cacert_file, len, "%s/%s", x509_dir, X509_CA_CERT_FILE); } } -- 2.9.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Xorg glx module: GLVND, EGL, or ... ?
On 12/15/2016 10:53 AM, Hans de Goede wrote: Hi, On 15-12-16 17:08, Emil Velikov wrote: On 15 December 2016 at 08:15, Michel Dänzer wrote: Hi Adam, Andy, Kyle, even with GLVND in place and used by Mesa and other GL implementations, one remaining issue preventing peaceful coexistence of Mesa based and other GLX implementations is that other GLX implementations tend to ship their own, mutually incompatible versions of the Xorg glx module. I'm not sure about all the reasons for this, but an important one is that the glx module in the xserver tree has been using the DRI driver interface directly, which can only work with Mesa. The "xfree86: Extend OutputClass config sections" series from Hans just landed. With it one can correctly attribute/select the correct libglx.so, which should tackle the issue ;-) Not if you want to run some apps one GPU and other apps on the other GPU ... Regards, Hans More specifically, to allow different drivers on different screens, we'll need to define some interface that would dispatch each GLX request to the appropriate driver. Basically, a server-side counterpart to libglvnd's libGLX.so. A server interface should be a lot simpler than the client interface, though. Everything runs on one thread, we only have to care about mapping based on XID's and context tags, we don't have to worry about multiple servers with different sets of vendors, we can ignore basically everything that libGLdispatch.so is needed for in the client, and the opcodes nicely define a dispatch table for us. Using EGL might work, although I don't know my way around the server well enough to comment on what that would take. The biggest problem that I see is that if you've got a single, common library that translates GLX requests to EGL calls, then how would a vendor library define a new GLX extension? Also note that they may or may not be mutually exclusive. If you can use libEGL.so to draw to a surface within the server, then I'd expect you could implement a vendor library that works by calling into EGL. Mind you, if you had two vendors trying to do that, then things would get hairy. -Kyle ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Xorg glx module: GLVND, EGL, or ... ?
Hi, On 15-12-16 17:08, Emil Velikov wrote: On 15 December 2016 at 08:15, Michel Dänzer wrote: Hi Adam, Andy, Kyle, even with GLVND in place and used by Mesa and other GL implementations, one remaining issue preventing peaceful coexistence of Mesa based and other GLX implementations is that other GLX implementations tend to ship their own, mutually incompatible versions of the Xorg glx module. I'm not sure about all the reasons for this, but an important one is that the glx module in the xserver tree has been using the DRI driver interface directly, which can only work with Mesa. The "xfree86: Extend OutputClass config sections" series from Hans just landed. With it one can correctly attribute/select the correct libglx.so, which should tackle the issue ;-) Not if you want to run some apps one GPU and other apps on the other GPU ... Regards, Hans ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Xorg glx module: GLVND, EGL, or ... ?
On 15 December 2016 at 08:15, Michel Dänzer wrote: > > Hi Adam, Andy, Kyle, > > > even with GLVND in place and used by Mesa and other GL implementations, > one remaining issue preventing peaceful coexistence of Mesa based and > other GLX implementations is that other GLX implementations tend to ship > their own, mutually incompatible versions of the Xorg glx module. I'm > not sure about all the reasons for this, but an important one is that > the glx module in the xserver tree has been using the DRI driver > interface directly, which can only work with Mesa. > The "xfree86: Extend OutputClass config sections" series from Hans just landed. With it one can correctly attribute/select the correct libglx.so, which should tackle the issue ;-) > Adam, IIRC you previously mentioned the possibility of making the > xserver glx module use EGL instead of the DRI driver interface. Another > possibility might be to make it use GLVND. Is my understanding correct > that those are basically two mutually exclusive approaches for > addressing this issue? Maybe there's even more options I'm not aware of? > On the topic of using reimplementing DRI modules in terms of EGL I'm slightly worried since this means a) new code (bugs, testing, etc.) which very few people know and b) mixing APIs might end up nasty (see below) not to mention the unnecessary complexity/overhead that we'll get since we'll be going through GLVND every time. Example: Would happen if we one calls glXMakeCurrent which internally goes down to eglMakeCurrent ? Are we going to clash since (iirc) one is not allowed to do both on the same GL ctx ? Some food for thought... considering I've not lost it and the above sounds about right :-) Emil ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [qxl] Xspice: Replace malloc/strdup use with xnfalloc/xnfstrdup
Hi, On 15-12-16 10:57, Christophe Fergeau wrote: spiceqxl_*.c files are Xspice-only code. They contain a few uses of malloc/strdup, and none of these are checked for failure. It's better to replace these with xfnalloc/xnfstrdup which are provided by the X server and cannot fail (aborts on failure). Signed-off-by: Christophe Fergeau LGTM: Reviewed-by: Hans de Goede Regards, Hans --- src/spiceqxl_audio.c| 2 +- src/spiceqxl_main_loop.c| 4 ++-- src/spiceqxl_spice_server.c | 12 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/spiceqxl_audio.c b/src/spiceqxl_audio.c index 52a45f0..ec9260d 100644 --- a/src/spiceqxl_audio.c +++ b/src/spiceqxl_audio.c @@ -405,7 +405,7 @@ static void handle_one_change(qxl_screen_t *qxl, struct inotify_event *e) return; } -fname = malloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 1); +fname = xnfalloc(strlen(e->name) + strlen(qxl->playback_fifo_dir) + 1 + 1); strcpy(fname, qxl->playback_fifo_dir); strcat(fname, "/"); strcat(fname, e->name); diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c index c9894bb..669e116 100644 --- a/src/spiceqxl_main_loop.c +++ b/src/spiceqxl_main_loop.c @@ -209,7 +209,7 @@ int watch_count = 0; static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void *opaque) { -SpiceWatch *watch = malloc(sizeof(SpiceWatch)); +SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch)); DPRINTF(0, "adding %p, fd=%d at %d", watch, fd, watch_count); @@ -376,7 +376,7 @@ static int watch_update_mask_internal(SpiceWatch *watch, int event_mask) static SpiceWatch *watch_add(int fd, int event_mask, SpiceWatchFunc func, void *opaque) { -SpiceWatch *watch = malloc(sizeof(SpiceWatch)); +SpiceWatch *watch = xnfalloc(sizeof(SpiceWatch)); DPRINTF(0, "adding %p, fd=%d", watch, fd); diff --git a/src/spiceqxl_spice_server.c b/src/spiceqxl_spice_server.c index 6e8cf50..38257d0 100644 --- a/src/spiceqxl_spice_server.c +++ b/src/spiceqxl_spice_server.c @@ -200,23 +200,23 @@ void xspice_set_spice_server_options(OptionInfoPtr options) len = strlen(x509_dir) + 32; if (x509_key_file_base) { -x509_key_file = strdup(x509_key_file_base); +x509_key_file = xnfstrdup(x509_key_file_base); } else { -x509_key_file = malloc(len); +x509_key_file = xnfalloc(len); snprintf(x509_key_file, len, "%s/%s", x509_dir, X509_SERVER_KEY_FILE); } if (x509_cert_file_base) { -x509_cert_file = strdup(x509_cert_file_base); +x509_cert_file = xnfstrdup(x509_cert_file_base); } else { -x509_cert_file = malloc(len); +x509_cert_file = xnfalloc(len); snprintf(x509_cert_file, len, "%s/%s", x509_dir, X509_SERVER_CERT_FILE); } if (x509_cacert_file_base) { -x509_cacert_file = strdup(x509_cert_file_base); +x509_cacert_file = xnfstrdup(x509_cert_file_base); } else { -x509_cacert_file = malloc(len); +x509_cacert_file = xnfalloc(len); snprintf(x509_cacert_file, len, "%s/%s", x509_dir, X509_CA_CERT_FILE); } } ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Xorg glx module: GLVND, EGL, or ... ?
Hi Adam, Andy, Kyle, even with GLVND in place and used by Mesa and other GL implementations, one remaining issue preventing peaceful coexistence of Mesa based and other GLX implementations is that other GLX implementations tend to ship their own, mutually incompatible versions of the Xorg glx module. I'm not sure about all the reasons for this, but an important one is that the glx module in the xserver tree has been using the DRI driver interface directly, which can only work with Mesa. Adam, IIRC you previously mentioned the possibility of making the xserver glx module use EGL instead of the DRI driver interface. Another possibility might be to make it use GLVND. Is my understanding correct that those are basically two mutually exclusive approaches for addressing this issue? Maybe there's even more options I'm not aware of? I'd be interested in any thoughts you guys could share on this topic, in particular on which of the above two options would be better. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel