2016 Elections to the X.Org Board of Directors and Approval to Changes of the X.Org By Laws

2016-02-22 Thread Peter Hutterer 
The X.Org Foundation is holding elections for

   - The Board of Directors
   - Adoption of changes to the By Laws.

Election Schedule
=

Nomination period Start:   Feb 24  00:00 UTC
Nomination period End: Mar 15   23:59 UTC  (3 weeks)
Deadline of X.Org
  membership application
  renewal: Mar 17   23:59 UTC
Publication of Candidates
   & start of Candiate QA: Mar 17  (2 weeks)
Election Start:Mar 30  00:00 UTC
Election End:  Apr 12  23:59 UTC   (2 weeks)

==
| PLEASE NOTE:
| The memberships of all X.Org Members were expired in Dec 2015!
| To participate in this election you MUST renew or apply for membership
| by the deadline mentioned above!
| Please go to http://members.x.org/ for membership application or renewal.
==

You will find updated info on the elections at:

http://www.x.org/wiki/BoardOfDirectors/Elections/2016/

Board Election
==

The terms of the following Board Members will end this year:


Alex Deucher,
Matt Dew,
Egbert Eich,
Keith Packard

There are 4 seats on the X.Org Board of Directors up for reelection.

The Elections overview page http://www.x.org/wiki/BoardOfDirectors/Elections/
describes the voting methods and process.

The election process starts with a 3 week nomination period.
If you would like to nominate yourself please send email to the election
committee , giving your
- name
- current professional affiliation
- a statement of contribution to X.Org or related technologies
- a personal statement


To vote or to be elected to the Board you need to be a Member of the
X.Org Foundation.
To be a Member of the X.Org Foundation you need to apply or renew your
membership until the end of the nomination period.

Changes to the By Laws of the X.Org Foundation
==

The X.Org Foundation plans to join SPI (Software in Public Interest).
SPI has given it's formal approval and invited the X.Org Foundation
to join.
In order to join the Members of the X.Org Foundation need to approve
this and need to approve a change to the By Laws of the X.Org Foundation.

This vote of the members on joining SPI and on changing the By Laws will
take place alongside the election to the BoD.

There will be a Q session on the SPI membership and the new By Laws
starting with the nomination period of the candidates.
(Please also see separate announcement).

==
| PLEASE NOTE:
| The vote to change the by-laws requires approval of 2/3 of the membership.
| Please do vote in this election.
==

Q
===

After the nomination period members have the chance to meet the candidates
and ask questions on the members mailing list members _AT_ x.org.

The Q session regarding the By Law changes and the joining SPI starts
immediately also on the members mailing list. A Q wiki page will also
be added.

Regards,
Peter, on behalf of the X.Org BoD
___
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: [PATCH xserver 2/2] xwayland: Correctly detect whether posix_fallocate exists

2016-02-22 Thread Jonas Ådahl 
On Fri, Feb 19, 2016 at 11:53:46AM +0100, Julien Cristau wrote:
> On Fri, Feb 19, 2016 at 15:08:13 +0800, Jonas Ådahl wrote:
> 
> > We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever
> > defined anywhere. This commit makes it so that this macro is defined if
> > the posix_fallocate is detected during configure.
> > 
> > Signed-off-by: Jonas Ådahl 
> 
> Hi,
> 
> any reason not to do the check unconditionally and put the define in
> dix-config.h?

The only reason is that the function checked is only used by the
xwayland ddx. It could just as well be added to dix-config.h if that is
preferred.


Jonas

> 
> Cheers,
> Julien
___
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: [PATCH v2] kdrive/evdev: update keyboard LEDs (#22302)

2016-02-22 Thread Adam Jackson 
On Mon, 2016-02-22 at 16:04 -0300, Laércio de Sousa wrote:

> @@ -442,10 +442,13 @@ EvdevKbdEnable(KdKeyboardInfo * ki)
>  static void
>  EvdevKbdLeds(KdKeyboardInfo * ki, int leds)
>  {
> -/*struct input_event event;
> +struct input_event event;
>  Kevdev *ke;
>  
> -ki->driverPrivate = ke;
> +ke = ki->driverPrivate;
> +
> +if (!ki || !ke)
> +return;

Sadly this won't work, if ki == NULL then ke will be loaded (and
trigger a segfault). Pushed a version with that fixed instead:

remote: E: failed to find patch for rev 
0461bca0cb2f7918c77ed45d2cbc756cf65021be.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   30b7d79..0461bca  master -> master

- ajax
___
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: Unplugging the main graphics device

2016-02-22 Thread Dave Airlie 
On 22 February 2016 at 22:20, Michael Thayer  wrote:
> On 19.02.2016 16:16, Michael Thayer wrote:
>>
>> I have been experimenting a bit with plugging and unplugging of graphics
>> devices (using a dummy KMS driver which is udl stripped of the actual
>> hardware poking) and how the X server copes with that.  It seems to cope
>> well with a secondary device being removed, but not with the only
>> graphics device in the system disappearing (in that case the
>> hot-pluggable device is not deemed to be a GPU device, and therefore not
>> removable if I understood what is happening correctly).
>>
>> This is interesting for me because I am looking at putting a KMS driver
>> for the VirtualBox video device into the upstream kernel, but would like
>> to be able to update the driver at run-time, so that we are not stuck
>> with whatever version some guest distribution which is no longer being
>> updated happens to provide.  My first idea for handling this was to
>> simulate a device unplug so that the old driver could be removed and the
>> new one added.  (Not sure if I am handling the hotplug right in the
>> vboxvideo driver yet of course, but I assume that my dummy driver, which
>> just copies code from udl, does get it right.)
>>
>> I will take a look at this when I get a chance of course, but I thought
>> I would write to the list before that in case anyone else has thoughts,
>> ideas or fixes (potenially including how I could better handle the
>> driver update).
>
>
> Re-reading the X server code a couple of days later makes it clear that this
> is intended.  The question is how I should best deal with this. Would people
> be open to having the first graphics device hot-removable too?  Obviously
> there are other use cases for this, like using DisplayLink with a headless
> embedded device.  But I realise that the X server was designed with the
> assumption that this will not happen.  Any other suggestions?  I doubt
> having a dummy first device which can stay in place would go down well
> elsewhere.
>

Install driver, ask user to reboot.

Trying to remove the first screen from X is a long and insanity
inspiring process.

I've spent months hacking up something that lets us migrate stuff from screen A
to screen B, but it's really messy and the current X server code doesn't lend
itself to it at all, so I pretty much gave up the last time I tried.

Dave.
___
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: [PATCH xserver] Fix build on Cygwin by ensuring WIN32 check triggers only on MinGW

2016-02-22 Thread Adam Jackson 
On Mon, 2016-02-22 at 16:20 +, Jon Turney wrote:
> The type of fd_mask was changed in Cygwin 2.4.0 headers from 'long' to 
> 'unsigned
> long'.  This exposes an existing problem with winauth.c, which includes
> Xwindows.h (which includes windows.h, which defines WIN32), before including
> osdep.h, which causes the now conflicting definition of fd_mask in osdep.h to 
> be
> exposed:
> 
> In file included from ../os/osdep.h:198:18: error: conflicting types for 
> ‘fd_mask’
>  typedef long int fd_mask;
> /usr/include/sys/select.h:46:23: note: previous declaration of ‘fd_mask’ was 
> here
>  typedef unsigned long fd_mask;
> 
> Adjust the include guards in osdep.h to make sure we only use WIN32 guarded 
> code
> when not compiling for Cygwin (i.e. WIN32 && !__CYGWIN__)
> 
> This isn't a very elegant, but unfortunately appears to be the best solution,
> since it doesn't seem to be possible to write the test in a positive form.
> 
> Future work: Should also audit of all the other uses of WIN32 in xserver, and
> make sure they are correct.

remote: I: patch #74619 updated using rev 
30b7d7995ef70b7473e0fb170eb8ae23b8d1f4a7.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   544b414..30b7d79  master -> master

- ajax
___
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: [PATCHv2] modesetting: Add common widescreen resolutions

2016-02-22 Thread Adam Jackson 
On Mon, 2016-02-22 at 11:41 -0500, Alex Deucher wrote:
> On Sun, Feb 21, 2016 at 6:12 AM, Adel Gadllah  wrote:
> > Stolen from the intel ddx driver, see:
> > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=26fd6bec
> > https://bugs.freedesktop.org/show_bug.cgi?id=37858
> > 
> > it makes those common modes selectable when using the modesetting driver.
> > 
> > Signed-off-by: Adel Gadllah 
> 
> NACK.  There's no reason to add this to the modesetting ddx.  Just fix
> it in the xserver.  E.g., they should be added to
> hw/xfree86/etc/extramodes.c as per
> https://bugs.freedesktop.org/show_bug.cgi?id=37858#c4

Indeed.  And also...

> 
> > +   for (n = 0; n < ARRAY_SIZE(common_16_9); n++) {
> > +   if (preferred->HDisplay <= 
> > common_16_9[n].width ||
> > +   preferred->VDisplay <= 
> > common_16_9[n].height)
> > +   break;
> > +
> > +   m = xf86GTFMode(common_16_9[n].width,
> > +   common_16_9[n].height,
> > +   xf86ModeVRefresh(preferred),
> > +   FALSE, FALSE);

xf86GTFMode is almost certainly the wrong thing to call unconditionally
from this kind of logic; I suspect the only reason it works for intel
is that the drm just ignores the timings you ask for and only looks at
the sizes. Ideally you'd be looking these timings up from the DMTModes
list (which is probably out of sync with the kernel's copy of it by
now), and you need to pay attention to the timing level supported by
the sink so you can know to generate CVT-R modes.

dmt:~% gtf 3840 2160 60 | grep Mode
  Modeline "3840x2160_60.00"  712.34  3840 4152 4576 5312  2160 2161 2164 2235  
-HSync +Vsync
dmt:~% cvt -r 3840 2160 60 | grep Mode
Modeline "3840x2160R"  533.00  3840 3888 3920 4000  2160 2163 2168  +hsync 
-vsync

A 180MHz difference in dotclock is... significant.

- ajax
___
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

[PATCH v2] kdrive/evdev: update keyboard LEDs (#22302)

2016-02-22 Thread Laércio de Sousa 
Implement missing parts in kdrive evdev driver for
correct update of evdev keyboard LEDs.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=22302

Signed-off-by: Laércio de Sousa 
---
 hw/kdrive/linux/evdev.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/kdrive/linux/evdev.c b/hw/kdrive/linux/evdev.c
index cdd45e7..a5b5954 100644
--- a/hw/kdrive/linux/evdev.c
+++ b/hw/kdrive/linux/evdev.c
@@ -442,10 +442,13 @@ EvdevKbdEnable(KdKeyboardInfo * ki)
 static void
 EvdevKbdLeds(KdKeyboardInfo * ki, int leds)
 {
-/*struct input_event event;
+struct input_event event;
 Kevdev *ke;
 
-ki->driverPrivate = ke;
+ke = ki->driverPrivate;
+
+if (!ki || !ke)
+return;
 
 memset(, 0, sizeof(event));
 
@@ -468,7 +471,6 @@ EvdevKbdLeds(KdKeyboardInfo * ki, int leds)
 event.code = LED_COMPOSE;
 event.value = leds & (1 << 3) ? 1 : 0;
 write(ke->fd, (char *) , sizeof(event));
-*/
 }
 
 static void
-- 
2.5.0

___
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: [PATCH xserver 1/2] xwayland: Prefix shm tmp file names with xwayland

2016-02-22 Thread Adam Jackson 
On Fri, 2016-02-19 at 15:08 +0800, Jonas Ådahl wrote:
> Prefix the temporary file names used for allocating pixmaps with
> "xwayland-" instead of "weston-". This makes it less confusing while
> looking at the file names of the currently open fds of the Xwayland
> process.
> 
> Signed-off-by: Jonas Ådahl 

remote: I: patch #74393 updated using rev 
544b4149268561d3d794aa540172831fa7550a20.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   5627708..544b414  master -> master

- ajax
___
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: [PATCH] dri2: add virtio-gpu pci ids

2016-02-22 Thread Adam Jackson 
On Tue, 2016-02-16 at 10:41 +1000, Dave Airlie wrote:
> On 13 February 2016 at 07:52, Marc-André Lureau
>  wrote:
> > Add virtio-gpu legacy + 1.0 pci ids, allowing them to use
> > modesetting + glamor with dri2.
> 
> Reviewed-by: Dave Airlie 

remote: I: patch #73717 updated using rev 
5627708e5f447d0e360bbc9eb8d1c4e58c5046d0.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   e957a2e..5627708  master -> master

- ajax
___
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: [PATCH kdrive/evdev] kdrive/evdev: update keyboard LEDs (#22302)

2016-02-22 Thread Laércio de Sousa 
Ah, yes! No problem! We can drop it.

2016-02-22 15:48 GMT-03:00 Adam Jackson :

> On Mon, 2016-02-15 at 11:32 -0200, Laércio de Sousa wrote:
>
> > Implement missing parts in kdrive evdev driver for
> > correct update of evdev keyboard LEDs.
>
> Hah! I like how this was there and just not wired up.
>
> > +if (!ke) {
> > +ErrorF("Can't update LEDs of disabled evdev keyboard %s.\n",
> ki->path);
> > +return;
> > +}
>
> I'm not a fan of error messages for routine conditions. If this is
> really a "shouldn't happen" case then fine, but it looks like this will
> emit a message every time you have >=1 disabled keyboards and hit
> CapsLock on an enabled keyboard. If I'm reading that correctly, can we
> just drop this message?
>
> - ajax
>



-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
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: [PATCH kdrive/evdev] kdrive/evdev: update keyboard LEDs (#22302)

2016-02-22 Thread Adam Jackson 
On Mon, 2016-02-15 at 11:32 -0200, Laércio de Sousa wrote:

> Implement missing parts in kdrive evdev driver for
> correct update of evdev keyboard LEDs.

Hah! I like how this was there and just not wired up.

> +if (!ke) {
> +ErrorF("Can't update LEDs of disabled evdev keyboard %s.\n", 
> ki->path);
> +return;
> +}

I'm not a fan of error messages for routine conditions. If this is
really a "shouldn't happen" case then fine, but it looks like this will
emit a message every time you have >=1 disabled keyboards and hit
CapsLock on an enabled keyboard. If I'm reading that correctly, can we
just drop this message?

- ajax
___
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: [PATCH v2] Add hybrid full-size/empty-clip mode to SetRootClip

2016-02-22 Thread Adam Jackson 
On Fri, 2016-02-12 at 16:36 +, Daniel Stone wrote:
> 216bdbc735 removed the SetRootClip call in the XWayland output-hotplug
> handler when running rootless (e.g. as a part of Weston/Mutter), since
> the root window has no storage, so generating exposures will result in
> writes to invalid memory.
> 
> Unfortunately, preventing the segfault also breaks sprite confinement.
> SetRootClip updates winSize and borderSize for the root window, which
> when combined with RRScreenSizeChanged calling ScreenRestructured,
> generates a new sprite-confinment area to update it to the whole screen.
> 
> Removing this call results in the window geometry being reported
> correctly, but winSize/borderSize never changing from their values at
> startup, i.e. out of sync with the root window geometry / screen
> information in the connection info / XRandR.
> 
> This patch introduces a hybrid mode, where we update winSize and
> borderSize for the root window, enabling sprite confinement to work
> correctly, but keep the clip emptied so exposures are never generated.
> 
> Signed-off-by: Daniel Stone 
> Tested-by: Olivier Fourdan 
> Cc: Adam Jackson 
> ---

Added a subsystem annotation to the summary line and merged:

remote: I: patch #73579 updated using rev 
e957a2e5dd288f515f3e93724823542c20333f6a.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   dbe8d03..e957a2e  master -> master

- ajax
___
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: [PATCHv2] modesetting: Add common widescreen resolutions

2016-02-22 Thread Alex Deucher 
On Sun, Feb 21, 2016 at 6:12 AM, Adel Gadllah  wrote:
> Stolen from the intel ddx driver, see:
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=26fd6bec
> https://bugs.freedesktop.org/show_bug.cgi?id=37858
>
> it makes those common modes selectable when using the modesetting driver.
>
> Signed-off-by: Adel Gadllah 

NACK.  There's no reason to add this to the modesetting ddx.  Just fix
it in the xserver.  E.g., they should be added to
hw/xfree86/etc/extramodes.c as per
https://bugs.freedesktop.org/show_bug.cgi?id=37858#c4

Alex

> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 107 
> ++-
>  1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0d34ca1..4faabcd 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -953,6 +953,111 @@ has_panel_fitter(xf86OutputPtr output)
>  return FALSE;
>  }
>
> +static struct pixel_count {
> +   int16_t width, height;
> +} common_16_9[] = {
> +   { 640, 360 },
> +   { 720, 405 },
> +   { 864, 486 },
> +   { 960, 540 },
> +   { 1024, 576 },
> +   { 1280, 720 },
> +   { 1366, 768 },
> +   { 1600, 900 },
> +   { 1920, 1080 },
> +   { 2048, 1152 },
> +   { 2560, 1440 },
> +   { 2880, 1620 },
> +   { 3200, 1800 },
> +   { 3840, 2160 },
> +   { 4096, 2304 },
> +   { 5120, 2880 },
> +   { 7680, 4320 },
> +   { 15360, 8640 },
> +}, common_16_10[] = {
> +   { 1280, 800 },
> +   { 1400, 900 },
> +   { 1680, 1050 },
> +   { 1920, 1200 },
> +   { 2560, 1600 },
> +};
> +
> +static bool
> +drmmode_output_is_duplicate_mode(DisplayModePtr modes, DisplayModePtr m)
> +{
> +   if (m == NULL)
> +   return false;
> +
> +   while (modes) {
> +   if (xf86ModesEqual(modes, m))
> +   return true;
> +
> +   modes = modes->next;
> +   }
> +
> +   return false;
> +}
> +
> +static DisplayModePtr
> +drmmode_output_get_default_modes(DisplayModePtr preferred)
> +{
> +DisplayModePtr modes;
> +int n;
> +
> +modes = xf86GetDefaultModes();
> +if (preferred) {
> +   DisplayModePtr m;
> +
> +   /* Add a half-resolution mode useful for large panels */
> +   m = xf86GTFMode(preferred->HDisplay / 2,
> +   preferred->VDisplay / 2,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 9 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 9 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_9); n++) {
> +   if (preferred->HDisplay <= 
> common_16_9[n].width ||
> +   preferred->VDisplay <= 
> common_16_9[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_9[n].width,
> +   common_16_9[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +   }
> +   }
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 10 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 10 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_10); n++) {
> +   if (preferred->HDisplay <= 
> common_16_10[n].width ||
> +   preferred->VDisplay <= 
> common_16_10[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_10[n].width,
> +   common_16_10[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +

[PATCH xserver] Fix build on Cygwin by ensuring WIN32 check triggers only on MinGW

2016-02-22 Thread Jon Turney 
The type of fd_mask was changed in Cygwin 2.4.0 headers from 'long' to 'unsigned
long'.  This exposes an existing problem with winauth.c, which includes
Xwindows.h (which includes windows.h, which defines WIN32), before including
osdep.h, which causes the now conflicting definition of fd_mask in osdep.h to be
exposed:

In file included from ../os/osdep.h:198:18: error: conflicting types for 
‘fd_mask’
 typedef long int fd_mask;
/usr/include/sys/select.h:46:23: note: previous declaration of ‘fd_mask’ was 
here
 typedef unsigned long fd_mask;

Adjust the include guards in osdep.h to make sure we only use WIN32 guarded code
when not compiling for Cygwin (i.e. WIN32 && !__CYGWIN__)

This isn't a very elegant, but unfortunately appears to be the best solution,
since it doesn't seem to be possible to write the test in a positive form.

Future work: Should also audit of all the other uses of WIN32 in xserver, and
make sure they are correct.

Signed-off-by: Jon Turney 
---
 os/osdep.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/os/osdep.h b/os/osdep.h
index 2fbfc48..3dc2daf 100644
--- a/os/osdep.h
+++ b/os/osdep.h
@@ -72,7 +72,7 @@ SOFTWARE.
 #if defined(NOFILE) && !defined(NOFILES_MAX)
 #define OPEN_MAX NOFILE
 #else
-#if !defined(WIN32)
+#if !defined(WIN32) || defined(__CYGWIN__)
 #define OPEN_MAX NOFILES_MAX
 #else
 #define OPEN_MAX 512
@@ -178,7 +178,7 @@ extern fd_set ClientsWriteBlocked;
 extern fd_set OutputPending;
 extern fd_set IgnoredClientsWithInput;
 
-#ifndef WIN32
+#if !defined(WIN32) || defined(__CYGWIN__)
 extern int *ConnectionTranslation;
 #else
 extern int GetConnectionTranslation(int conn);
@@ -193,7 +193,7 @@ extern Bool NumNotifyWriteFd;
 extern WorkQueuePtr workQueue;
 
 /* in WaitFor.c */
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
 typedef long int fd_mask;
 #endif
 #define ffs mffs
-- 
2.7.0

___
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: [PATCH kdrive/ephyr v8 0/4] Xephyr input hot-plugging support and other additions for single-GPU multi-seat

2016-02-22 Thread Laércio de Sousa 
2016-02-12 14:17 GMT-02:00 Laércio de Sousa <
laercioso...@sme-mogidascruzes.sp.gov.br>:

>   - During tests, I realized that some issues regarding input
> hot-plugging with evdev driver in kdrive only seems to affect
> Debian/Ubuntu systems, so I've dropped some pieces of code written
> to address such issues at upstream level.

Comparing Debian/Ubuntu and openSUSE source packages for xorg-server, I've
discovered that this FD unregistering issue was already fixed in commit
44d0fd435
,
released in version 1.18.1. This patch was backported to openSUSE's 1.17.2
package, but not to Ubuntu wily/xenial one. After backporting this patch to
my xorg-server packages in Ubuntu Multiseat PPA, this problem has gone.
-- 
*Laércio de Sousa*
*Orientador de Informática*
*Escola Municipal "Professor Eulálio Gruppi"*
*Rua Ismael da Silva Mello, 559, Mogi Moderno*
*Mogi das Cruzes - SPCEP 08717-390*
Telefone: (11) 4726-8313
___
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: Unplugging the main graphics device

2016-02-22 Thread Michael Thayer 

On 19.02.2016 16:16, Michael Thayer wrote:

I have been experimenting a bit with plugging and unplugging of graphics
devices (using a dummy KMS driver which is udl stripped of the actual
hardware poking) and how the X server copes with that.  It seems to cope
well with a secondary device being removed, but not with the only
graphics device in the system disappearing (in that case the
hot-pluggable device is not deemed to be a GPU device, and therefore not
removable if I understood what is happening correctly).

This is interesting for me because I am looking at putting a KMS driver
for the VirtualBox video device into the upstream kernel, but would like
to be able to update the driver at run-time, so that we are not stuck
with whatever version some guest distribution which is no longer being
updated happens to provide.  My first idea for handling this was to
simulate a device unplug so that the old driver could be removed and the
new one added.  (Not sure if I am handling the hotplug right in the
vboxvideo driver yet of course, but I assume that my dummy driver, which
just copies code from udl, does get it right.)

I will take a look at this when I get a chance of course, but I thought
I would write to the list before that in case anyone else has thoughts,
ideas or fixes (potenially including how I could better handle the
driver update).


Re-reading the X server code a couple of days later makes it clear that 
this is intended.  The question is how I should best deal with this. 
Would people be open to having the first graphics device hot-removable 
too?  Obviously there are other use cases for this, like using 
DisplayLink with a headless embedded device.  But I realise that the X 
server was designed with the assumption that this will not happen.  Any 
other suggestions?  I doubt having a dummy first device which can stay 
in place would go down well elsewhere.




Regards,

Michael


--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
___
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: [PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip

2016-02-22 Thread Michel Dänzer 
On 19.02.2016 14:31, Keith Packard wrote:
> Michel Dänzer  writes:
> 
> Here's another review, now that I've more carefully looked at the other
> two patches.
> 
>> +if (!flip_window || !flip_pixmap)
>> +return;
> 
> In the original code, this didn't abort the operation entirely...
> 
> This operation would have been skipped:
> 
>> +present_set_tree_pixmap(flip_window, flip_pixmap, screen_pixmap);
> 
> But this operation would not:
> 
>> +present_set_tree_pixmap(screen->root, NULL, screen_pixmap);

BTW, it might be safer to make this

present_set_tree_pixmap(screen->root, flip_pixmap, screen_pixmap);

as well, so the root window pixmap is only changed to the screen pixmap
if it's currently the flip pixmap? Anyway, this can be done in a
followup, since the current call with NULL doesn't seem to cause any
problem in practice.


> Reading the rest of the code, I can't find a case which could call this
> with a null flip_window or flip_pixmap;

While I couldn't either just looking at present.c, I can get it called
with flip_window == NULL when pressing Escape while glxgears is flipping
in fullscreen, presumably due to present_clear_window_flip.

I'm not sure the present_copy_region or
present_set_tree_pixmap(screen->root, ...) calls will ever have any
actual effect in this case, but for now let's preserve the logic of the
refactored code wrt this.


-- 
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

[PATCH v2 xserver 3/3] present: Call present_restore_screen_pixmap from present_set_abort_flip

2016-02-22 Thread Michel Dänzer 
From: Michel Dänzer 

After present_set_abort_flip, the screen pixmap will be used for all
screen drawing, so we need to restore the current flip pixmap contents
to the screen pixmap here as well.

Improves flashing / stutter e.g. when something like a popup menu appears
on top of a flipping fullscreen window or when switching out of
fullscreen.

Note that this means present_set_abort_flip now relies on screen->root
being non-NULL, but that's already the case in other present code.

Reviewed-by: Keith Packard 
Reviewed-by: Chris Wilson 
Signed-off-by: Michel Dänzer 
---

v2: Rebased on top of v2 of patch 2.

 present/present.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/present/present.c b/present/present.c
index 63ad275..f96ea94 100644
--- a/present/present.c
+++ b/present/present.c
@@ -396,8 +396,16 @@ present_restore_screen_pixmap(ScreenPtr screen)
 {
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
 PixmapPtr screen_pixmap = (*screen->GetScreenPixmap)(screen);
-PixmapPtr flip_pixmap = screen_priv->flip_pixmap;
-WindowPtr flip_window = screen_priv->flip_window;
+PixmapPtr flip_pixmap;
+WindowPtr flip_window;
+
+if (screen_priv->flip_pending) {
+flip_window = screen_priv->flip_pending->window;
+flip_pixmap = screen_priv->flip_pending->pixmap;
+} else {
+flip_window = screen_priv->flip_window;
+flip_pixmap = screen_priv->flip_pixmap;
+}
 
 assert (flip_pixmap);
 
@@ -408,6 +416,9 @@ present_restore_screen_pixmap(ScreenPtr screen)
 if (screen->GetWindowPixmap(screen->root) == flip_pixmap)
 present_copy_region(_pixmap->drawable, flip_pixmap, NULL, 0, 0);
 
+/* Switch back to using the screen pixmap now to avoid
+ * 2D applications drawing to the wrong pixmap.
+ */
 if (flip_window)
 present_set_tree_pixmap(flip_window, flip_pixmap, screen_pixmap);
 present_set_tree_pixmap(screen->root, NULL, screen_pixmap);
@@ -417,19 +428,8 @@ static void
 present_set_abort_flip(ScreenPtr screen)
 {
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
-PixmapPtr pixmap = (*screen->GetScreenPixmap)(screen);
 
-/* Switch back to using the screen pixmap now to avoid
- * 2D applications drawing to the wrong pixmap.
- */
-
-if (screen_priv->flip_window)
-present_set_tree_pixmap(screen_priv->flip_window,
-screen_priv->flip_pixmap,
-pixmap);
-
-if (screen->root)
-present_set_tree_pixmap(screen->root, NULL, pixmap);
+present_restore_screen_pixmap(screen);
 
 screen_priv->flip_pending->abort_flip = TRUE;
 }
-- 
2.7.0

___
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

[PATCH xserver 2/3] present: Factor code for restoring screen pixmap out of present_unflip (v2)

2016-02-22 Thread Michel Dänzer 
From: Michel Dänzer 

The following fix will use the refactored function.

The logic in the refactored function is slightly simplified, exploiting
the fact that this function is only ever called with a valid flip
pixmap.

v2: Assert that flip_pixmap is non-NULL instead of testing and bailing
on NULL, preserve test for flip_window being non-NULL before calling
present_set_tree_pixmap for it (Keith Packard)

Reviewed-by: Chris Wilson  (v1)
Signed-off-by: Michel Dänzer 
---
 present/present.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/present/present.c b/present/present.c
index d6ec895..63ad275 100644
--- a/present/present.c
+++ b/present/present.c
@@ -392,6 +392,28 @@ present_set_tree_pixmap(WindowPtr window,
 }
 
 static void
+present_restore_screen_pixmap(ScreenPtr screen)
+{
+present_screen_priv_ptr screen_priv = present_screen_priv(screen);
+PixmapPtr screen_pixmap = (*screen->GetScreenPixmap)(screen);
+PixmapPtr flip_pixmap = screen_priv->flip_pixmap;
+WindowPtr flip_window = screen_priv->flip_window;
+
+assert (flip_pixmap);
+
+/* Update the screen pixmap with the current flip pixmap contents
+ * Only do this the first time for a particular unflip operation, or
+ * we'll probably scribble over other windows
+ */
+if (screen->GetWindowPixmap(screen->root) == flip_pixmap)
+present_copy_region(_pixmap->drawable, flip_pixmap, NULL, 0, 0);
+
+if (flip_window)
+present_set_tree_pixmap(flip_window, flip_pixmap, screen_pixmap);
+present_set_tree_pixmap(screen->root, NULL, screen_pixmap);
+}
+
+static void
 present_set_abort_flip(ScreenPtr screen)
 {
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
@@ -416,26 +438,11 @@ static void
 present_unflip(ScreenPtr screen)
 {
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
-PixmapPtr pixmap = (*screen->GetScreenPixmap)(screen);
 
 assert (!screen_priv->unflip_event_id);
 assert (!screen_priv->flip_pending);
 
-/* Update the screen pixmap with the current flip pixmap contents
- * Only do this the first time for a particular unflip operation, or
- * we'll probably scribble over other windows
- */
-if (screen->GetWindowPixmap(screen->root) == screen_priv->flip_pixmap) {
-present_copy_region(>drawable, screen_priv->flip_pixmap,
-NULL, 0, 0);
-}
-
-if (screen_priv->flip_pixmap && screen_priv->flip_window)
-present_set_tree_pixmap(screen_priv->flip_window,
-screen_priv->flip_pixmap,
-pixmap);
-
-present_set_tree_pixmap(screen->root, NULL, pixmap);
+present_restore_screen_pixmap(screen);
 
 screen_priv->unflip_event_id = ++present_event_id;
 DebugPresent(("u %lld\n", screen_priv->unflip_event_id));
-- 
2.7.0

___
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: [PATCH] modesetting: Add common widescreen resolutions

2016-02-22 Thread Daniel Martin 
On 21 February 2016 at 12:08, Adel Gadllah  wrote:
> Stolen from the intel ddx driver, see:
> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=26fd6bec
> https://bugs.freedesktop.org/show_bug.cgi?id=37858
>
> it makes those common modes selectable when using the modesetting driver.
>
> Signed-off-by: Adel Gadllah 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 107 
> ++-
>  1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0d34ca1..078b497 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -953,6 +953,111 @@ has_panel_fitter(xf86OutputPtr output)
>  return FALSE;
>  }
>
> +static struct pixel_count {
> +   int16_t width, height;
> +} common_16_9[] = {
> +   { 640, 360 },
> +   { 720, 405 },
> +   { 864, 486 },
> +   { 960, 540 },
> +   { 1024, 576 },
> +   { 1280, 720 },
> +   { 1366, 768 },
> +   { 1600, 900 },
> +   { 1920, 1080 },
> +   { 2048, 1152 },
> +   { 2560, 1440 },
> +   { 2880, 1620 },
> +   { 3200, 1800 },
> +   { 3840, 2160 },
> +   { 4096, 2304 },
> +   { 5120, 2880 },
> +   { 7680, 4320 },
> +   { 15360, 8640 },
> +}, common_16_10[] = {
> +   { 1280, 800 },
> +   { 1400, 900 },
> +   { 1680, 1050 },
> +   { 1920, 1200 },
> +   { 2560, 1600 },
> +};
> +
> +static bool
> +drmmode_output_is_duplicate_mode(DisplayModePtr modes, DisplayModePtr m)
> +{
> +   if (m == NULL)
> +   return false;
> +
> +   while (modes) {
> +   if (xf86ModesEqual(modes, m))
> +   return true;
> +
> +   modes = modes->next;
> +   }
> +
> +   return false;
> +}
> +
> +static DisplayModePtr
> +drmmode_output_get_default_modes(DisplayModePtr preferred)
> +{
> +DisplayModePtr modes;
> +int n;
> +
> +modes = xf86GetDefaultModes();
> +if (preferred) {

I would prefer to invert this check. Then you don't need to indent the
following block.

> +   DisplayModePtr m;
> +
> +   /* Add a half-resolution mode useful for large panels */
> +   m = xf86GTFMode(preferred->HDisplay / 2,
> +   preferred->VDisplay / 2,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 9 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 9 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_9); n++) {
> +   if (preferred->HDisplay <= 
> common_16_9[n].width ||
> +   preferred->VDisplay <= 
> common_16_9[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_9[n].width,
> +   common_16_9[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +   }
> +   }
> +
> +   if (preferred->VDisplay * 16 > preferred->HDisplay * 10 - 
> preferred->HDisplay / 32 &&
> +   preferred->VDisplay * 16 < preferred->HDisplay * 10 + 
> preferred->HDisplay / 32) {
> +   for (n = 0; n < ARRAY_SIZE(common_16_10); n++) {
> +   if (preferred->HDisplay <= 
> common_16_10[n].width ||
> +   preferred->VDisplay <= 
> common_16_10[n].height)
> +   break;
> +
> +   m = xf86GTFMode(common_16_10[n].width,
> +   common_16_10[n].height,
> +   xf86ModeVRefresh(preferred),
> +   FALSE, FALSE);
> +   if (!drmmode_output_is_duplicate_mode(modes, 
> m))
> +   modes = xf86ModesAdd(modes, m);
> +   else
> +   free(m);
> +   }
> +   }
> +