Another protocol repository merge attempt

["Keith Packard"]

The idea of merging all of our X protocol repositories came up again,
and Adam Jackson asked if I wanted to wait for this before merging my
randr lease/non-desktop changes.

Not really? But, I'm still interested in a merge of the protocol
repositories; we've got way too many, and they're mostly tiny.

Ok, so I gave another run at this, with a slightly different goal. I
want to avoid renaming files as that makes history tracking a bit harder
to manage. So, what I did was find all of the filenames which are
duplicated between repositories. It's a short list:

.gitignore
AUTHORS
autogen.sh
configure.ac
COPYING
docbook.am
Makefile.am
README
specs/Makefile.am
specs/.gitignore

Then I generated some scripts that would merge in a repo, move the
(potentially) conflicting files to a directory named after the source
repo and commit that move.

Another script to merge the Makefile.am contents and I've got a
repository which installs all of the header files at least. It doesn't
build the docs for anything, and in fact all of the docs are mashed into
a 'specs' sub-directory

I don't know if this is more or less useful than the earlier plan which
placed each extension in a sub-directory; I'm good either way, I just
want to finish this up and get back to more interesting work.

Take a look and let me know what you think.

git clone git://people.freedesktop.org/~keithp/mergeproto

This was less than an hours work; if the consensus is 'yuck', you won't
hurt my feelings at all.

-- 
-keith


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: monitor hotplug resolution switch

[Felix Miata]

Johann Obermayr composed on 2017-12-13 15:07 (UTC):

> now i have compile 2.99.917 and enable VirtualHeads in the xorg.conf.

> xrandr --newmode "1920x1080" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 
> xrandr --addmode VIRTUAL1 "1920x1080"
> xrandr --output VIRTUAL1 --mode "1920x1080"

> now it looks like it works.
> The resolution is always 1920x1080, even if I connect / disconnect 
> DisplayPort or HDMI Monitor.

> Can I put this settings into the xorg.conf ?
> Or is xrandr the only way ?

Setting in xorg.conf was the only way before xrandr existed. Setting in
xorg.conf may cause those settings to be applied sooner as well, so that they
affect any GUI login manager that might be starting, instead of at later window
manager startup.

Also, you *should* need *no* modelines if you include valid values for these
three options:

VertRefresh
HorizSync
PreferredMode

I've *never* needed to include modelines to produce the resolution I want. Xorg
knows how to auto-generate modelines quite well given those basic substitutes
for a display's EDID.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

AW: monitor hotplug resolution switch

[Johann Obermayr]

Hello,

now i have compile 2.99.917 and enable VirtualHeads in the xorg.conf.

xrandr --newmode "1920x1080" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 
xrandr --addmode VIRTUAL1 "1920x1080"
xrandr --output VIRTUAL1 --mode "1920x1080"


now it looks like it works.
The resolution is always 1920x1080, even if I connect / disconnect DisplayPort 
or HDMI Monitor.

Can I put this settings into the xorg.conf ?
Or is xrandr the only way ?

Thanks & regards
  Johann

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: AW: AW: AW: monitor hotplug resolution switch

[j...@dodin.org]

Le 13/12/2017 à 20:53, Johann Obermayr a écrit :



Now I'm search a way to set this 3 line with the xrandr extensions library.


did you look here?

http://dodin.org/wiki/pmwiki.php?n=Doc.AddXResolution#toc3

it need to be in a script at launch after X starts, for me simply 
launched by kde


jdd



--
http://dodin.org
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

AW: AW: AW: monitor hotplug resolution switch

[Johann Obermayr]

Hello,

> -Ursprüngliche Nachricht-
> Von: xorg [mailto:xorg-boun...@lists.x.org] Im Auftrag von j...@dodin.org
> Gesendet: Mittwoch, 13. Dezember 2017 20:05
> An: xorg@lists.x.org
> Betreff: Re: AW: AW: monitor hotplug resolution switch
> 
> Le 13/12/2017 à 11:14, Johann Obermayr a écrit :
> 
> > We are using VNC.
> >
> 
> so you need a way to set a resolution in VNC, I did that but so long time ago 
> I
> don't recall how :-(
> 
> sorry
> jdd
> 
> 
> --
> http://dodin.org
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s

Thanks for help,

i think , i have found a solution.

Use newest xf86-video-intel 2.99.917
Enable SNA (+virtual output)
Enable virtual output in the xorg.conf. (Option  "VirtualHeads"  "2")

Call follow line after X started

xrandr --newmode "1280x1024@VIRT"  138.75  1280 1368 1504 1728  1024 1027 1034 
1072
xrandr --addmode VIRTUAL1 "1280x1024@VIRT"
xrandr --output VIRTUAL1 --mode "1280x1024@VIRT"

with xrandr I see always the same resolution at the current value.
Also with connect/disconnect HDMI/DP.

Now I'm search a way to set this 3 line with the xrandr extensions library.

Best regards
  Johann
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH xserver 1/2] os: Fix a type error in the IPv6 XDMCP code

[Adam Jackson]

Building with strict-aliasing rightly chirps here:

../os/xdmcp.c: In function ‘XdmcpRegisterConnection’:
../os/xdmcp.c:489:31: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
 &((struct sockaddr_in6 *) )->sin6_addr.s6_addr[12];
   ^~~~

We have "const char *address", so  here is a char ** (i.e., it
points to the slot on the stack containing the pointer to the character
array passed in as an argument). Casting that to a struct sockaddr_in6 *
is wrong, because it means that area of the stack will be reinterpreted
as a struct sockaddr_in6.

Instead, cast address, not 

Signed-off-by: Adam Jackson 
---
 os/xdmcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/os/xdmcp.c b/os/xdmcp.c
index 7aeb393e63..d8c81fbf83 100644
--- a/os/xdmcp.c
+++ b/os/xdmcp.c
@@ -486,7 +486,7 @@ XdmcpRegisterConnection(int type, const char *address, int 
addrlen)
  IN6_IS_ADDR_V4MAPPED((const struct in6_addr *) address)) {
 fromAddr = &((struct sockaddr_in *) )->sin_addr;
 regAddr =
-&((struct sockaddr_in6 *) )->sin6_addr.s6_addr[12];
+&((struct sockaddr_in6 *) address)->sin6_addr.s6_addr[12];
 regAddrlen = sizeof(struct in_addr);
 }
 }
-- 
2.14.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

[PATCH xserver 2/2] build: Drop -fno-strict-aliasing

[Adam Jackson]

For the autotools build this won't have any effect until a new
util-macros package is released.

Signed-off-by: Adam Jackson 
---
 configure.ac | 6 --
 meson.build  | 1 -
 2 files changed, 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 456a9e0a96..5260f1f082 100644
--- a/configure.ac
+++ b/configure.ac
@@ -85,12 +85,6 @@ XORG_PROG_RAWCPP
 # easier overrides at build time.
 XSERVER_CFLAGS='$(CWARNFLAGS)'
 
-dnl Explicitly add -fno-strict-aliasing since this option should disappear
-dnl from util-macros CWARNFLAGS
-if  test "x$GCC" = xyes ; then
-XSERVER_CFLAGS="$XSERVER_CFLAGS -fno-strict-aliasing"
-fi
-
 dnl Check for dtrace program (needed to build Xserver dtrace probes)
 dnl Also checks for , since some Linux distros have an 
 dnl ISDN trace program named dtrace
diff --git a/meson.build b/meson.build
index c028cc8aa7..da21d3441d 100644
--- a/meson.build
+++ b/meson.build
@@ -9,7 +9,6 @@ project('xserver', 'c',
 add_project_arguments('-DHAVE_DIX_CONFIG_H', language: 'c')
 cc = meson.get_compiler('c')
 
-add_global_arguments('-fno-strict-aliasing', language : 'c')
 add_global_arguments('-fvisibility=hidden', language : 'c')
 
 add_global_link_arguments('-fvisibility=hidden', language : 'c')
-- 
2.14.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: [PATCH util/macros] Drop -fno-strict-aliasing from XORG_CWARNFLAGS

[Adam Jackson]

On Wed, 2017-12-13 at 11:31 -0800, Keith Packard wrote:
> Adam Jackson  writes:
> 
> > This has been "deprecated" since 2011, but because it is still
> > referenced from XORG_DEFAULT_OPTIONS nothing has ever been updated to
> > get strict aliasing right. Let's fix that.
> 
> I don't understand this -- are you getting rid of this option from our
> compiles or not?

I mean, the lines in the diff start with "-".  "Let's fix that" here
means "let's build normally and see what falls out".

> I can assure you that our code is unlikely to work with
> out it.

xserver still passes make check when built without it. Well, the meson
build does anyway, I haven't gotten around to trying it with the
autotools build yet, nor adding -Werror=strict-aliasing and rebuilding
the world, but that would obviously be prerequisite for releasing a
version of util-macros with this change in it.

- 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: Merged repo for protocol headers? Why are they split?

[Daniel Martin]

Am 07.12.2017 17:18 schrieb "Emil Velikov" :

On 6 December 2017 at 12:37, Daniel Martin  wrote:
> Hi all,
>
> if anyone would like to have a look, I've pushed my current work on
> the merged proto repo here:
> https://github.com/bartsch/xorg-proto2k/
> It's generated as is with:
> https://github.com/bartsch/proto2k-generator/
>
> I used git-filter-branch to:
> - move files to specific directories and
> - prefix commit subjects with the proto name.
>
> Lots of files have been moved to tmp/, which was removed at the end.
> See commit "Remove temporary files (tmp/)".
>
> Atm, it just installs:
> - headers (+handling Xfuncproto.h and Xpoll.h) and
> - pkg-configs for each proto (haven't found any notable diff'erences
> to my distro pkg-configs)
>
> Now:
> - What should I do with the {AUTHORS,COPYING}.$proto files?
> - Should I remove some protos (i.e. trapproto)? The current list is:
> https://github.com/bartsch/xorg-proto2k/commit/
8b06f111f99c2f66a9327ef669ee17c530e7
> - Anything else I should change?
>
> Next:
> - I'm working on generating the specs.
>
Silly question: why are you moving things around?


I did that to reflect the installation hierarchy (at least for the headers)
and filter out files (i.e. autofoo and Makefiles) we don't need later.

Perhaps I misread something, but it seemed that devs prefer to have
the different repos in separate folders.
Aka something like
for repo in $repos; do
mv .../old/to/old/repo/$repo .../new/to/newrepo/$repo
done


I had the impression that this was the preferred way with git-subtree as it
doesn't allow us anything else without conflicts.

The repo you're prepared looks quite messy IMHO.


Can you be more specific, please? The mixed header files?

I can and will change stuff. I just need someone saying: We would like to
have it like ...
Though, not this week as I've a full time RL task atm..

Cheers,
Daniel
___
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 util/macros] Drop -fno-strict-aliasing from XORG_CWARNFLAGS

[Keith Packard]

Adam Jackson  writes:

> This has been "deprecated" since 2011, but because it is still
> referenced from XORG_DEFAULT_OPTIONS nothing has ever been updated to
> get strict aliasing right. Let's fix that.

I don't understand this -- are you getting rid of this option from our
compiles or not? I can assure you that our code is unlikely to work with
out it.

-- 
-keith


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: AW: AW: monitor hotplug resolution switch

[j...@dodin.org]

Le 13/12/2017 à 11:14, Johann Obermayr a écrit :


We are using VNC.



so you need a way to set a resolution in VNC, I did that but so long 
time ago I don't recall how :-(


sorry
jdd


--
http://dodin.org
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH util/macros] Drop -fno-strict-aliasing from XORG_CWARNFLAGS

[Adam Jackson]

This has been "deprecated" since 2011, but because it is still
referenced from XORG_DEFAULT_OPTIONS nothing has ever been updated to
get strict aliasing right. Let's fix that.

Signed-off-by: Adam Jackson 
---
 xorg-macros.m4.in | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index efce888..2c34cab 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -1750,20 +1750,19 @@ AC_SUBST([BASE_]PREFIX[FLAGS])
 #
 # Defines CWARNFLAGS to enable C compiler warnings.
 #
-# This function is deprecated because it defines -fno-strict-aliasing
+# This function was deprecated because it defined -fno-strict-aliasing
 # which alters the code generated by the compiler.  If -fno-strict-aliasing
 # is needed, then it should be added explicitly in the module when
 # it is updated to use BASE_CFLAGS.
 #
+# It now no longer adds the flag, but is still referenced in order to keep
+# CWARNFLAGS working as before.
 AC_DEFUN([XORG_CWARNFLAGS], [
 AC_REQUIRE([XORG_COMPILER_FLAGS])
 AC_REQUIRE([XORG_COMPILER_BRAND])
 AC_LANG_CASE(
[C], [
CWARNFLAGS="$BASE_CFLAGS"
-   if  test "x$GCC" = xyes ; then
-   CWARNFLAGS="$CWARNFLAGS -fno-strict-aliasing"
-   fi
AC_SUBST(CWARNFLAGS)
]
 )
-- 
2.14.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

AW: AW: monitor hotplug resolution switch

[Johann Obermayr]

Hi,

Thanks for helping.
regards
  Johann

> -Ursprüngliche Nachricht-
> Von: xorg [mailto:xorg-boun...@lists.x.org] Im Auftrag von j...@dodin.org
> Gesendet: Mittwoch, 13. Dezember 2017 10:22
> An: xorg@lists.x.org
> Betreff: Re: AW: monitor hotplug resolution switch
> 
> Le 13/12/2017 à 09:36, Johann Obermayr a écrit :
> 
> > root@sigmatek-x86-mp:~# xrandr
> > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> > VGA1 disconnected
> > DP1 disconnected
> > HDMI1 disconnected
> > DP2 disconnected
> > HDMI2 disconnected
> > DP3 connected
> > 1920x1080  60.0 +
> > HDMI3 disconnected
> >
> >
> > But after disconnect the monitor, the driver will change resolution to
> 320x200.
> > But we will, that driver does not change the resolution. Or we can define
> the default resolution.
> >
> 
> what mean "default resolution" if no monitor is connected?

I mean, it is a define resolution, same as your monitor.
We have different monitors with different resolution.
But our customer set the used resolution In a config file.
The resolution must be always the same. With or without monitor.
But now, if the monitor is disconnect, the resolution will change to 320x200.

> 
> seems it's simply the lower resolution available
> 
> do you need some remote X?

We are using VNC.

> 
> you can play with xrandr

I will do that.
I also looking for the "virtual" extention in the new xf86-video-intel driver.

> 
> http://dodin.org/wiki/pmwiki.php?n=Doc.AddXResolution
> 
> but with no monitor I dunno what happen nor what is the config for remote
> X desktop
> 
> jdd
> 
> 
> --
> http://dodin.org
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] xfree86: Hold input_lock across SPRITE functions in VGA arbiter

[Adam Jackson]

On Wed, 2017-08-02 at 21:34 -0700, Keith Packard wrote:
> Avoid scrambling the sprite functions wrapper.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101995
> Signed-off-by: Keith Packard 
> ---
>  hw/xfree86/common/xf86VGAarbiterPriv.h | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)

remote: I: patch #170077 updated using rev 
cf7517675d988c2d1ff967d6d162a17acbdad466.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   3265d0c81f..cf7517675d  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

[PATCH xserver 2/2] glx: Enable GLX_ARB_create_context_no_error

[Adam Jackson]

This is mostly for the client library's convenience, if this extension
is listed then it can know the attribute won't be rejected. Note that we
don't _do_ anything with this attribute, meaning indirect contexts will
not be no-error. That's fine, we don't want to introduce undefined
behavior into a potentially privileged process anyway.

Signed-off-by: Adam Jackson 
---
 glx/extension_string.c | 1 +
 glx/extension_string.h | 1 +
 glx/glxdri2.c  | 2 ++
 glx/glxdriswrast.c | 2 ++
 4 files changed, 6 insertions(+)

diff --git a/glx/extension_string.c b/glx/extension_string.c
index 102f9dd42b..354ce06f71 100644
--- a/glx/extension_string.c
+++ b/glx/extension_string.c
@@ -74,6 +74,7 @@ static const struct extension_info known_glx_extensions[] = {
 /* *INDENT-OFF* */
 { GLX(ARB_context_flush_control),   VER(0,0), N, },
 { GLX(ARB_create_context),  VER(0,0), N, },
+{ GLX(ARB_create_context_no_error), VER(0,0), N, },
 { GLX(ARB_create_context_profile),  VER(0,0), N, },
 { GLX(ARB_create_context_robustness), VER(0,0), N, },
 { GLX(ARB_fbconfig_float),  VER(0,0), N, },
diff --git a/glx/extension_string.h b/glx/extension_string.h
index f049f58400..eab385a3c7 100644
--- a/glx/extension_string.h
+++ b/glx/extension_string.h
@@ -38,6 +38,7 @@ enum {
 /*   GLX_ARB_get_proc_address is implemented on the client. */
 ARB_context_flush_control_bit = 0,
 ARB_create_context_bit,
+ARB_create_context_no_error_bit,
 ARB_create_context_profile_bit,
 ARB_create_context_robustness_bit,
 ARB_fbconfig_float_bit,
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 28d5a3a9c0..52c786977d 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -832,6 +832,8 @@ initializeExtensions(__GLXscreen * screen)
 if (dri->dri2->base.version >= 3) {
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_ARB_create_context");
+__glXEnableExtension(screen->glx_enable_bits,
+ "GLX_ARB_create_context_no_error");
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_ARB_create_context_profile");
 __glXEnableExtension(screen->glx_enable_bits,
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index caad9a1fe7..2858312de7 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdriswrast.c
@@ -356,6 +356,8 @@ initializeExtensions(__GLXscreen * screen)
 if (dri->swrast->base.version >= 3) {
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_ARB_create_context");
+__glXEnableExtension(screen->glx_enable_bits,
+ "GLX_ARB_create_context_no_error");
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_ARB_create_context_profile");
 __glXEnableExtension(screen->glx_enable_bits,
-- 
2.14.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

[PATCH xserver 1/2] glx: Stop printing messages about what GLX extensions we enable

[Adam Jackson]

glxinfo already exists, use it.

Signed-off-by: Adam Jackson 
---
 glx/glxdri2.c  | 29 +++--
 glx/glxdriswrast.c |  3 ---
 2 files changed, 3 insertions(+), 29 deletions(-)

diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 2e24b56e6c..28d5a3a9c0 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -827,10 +827,7 @@ initializeExtensions(__GLXscreen * screen)
 extensions = dri->core->getExtensions(dri->driScreen);
 
 __glXEnableExtension(screen->glx_enable_bits, "GLX_MESA_copy_sub_buffer");
-LogMessage(X_INFO, "AIGLX: enabled GLX_MESA_copy_sub_buffer\n");
-
 __glXEnableExtension(screen->glx_enable_bits, "GLX_EXT_no_config_context");
-LogMessage(X_INFO, "AIGLX: enabled GLX_EXT_no_config_context\n");
 
 if (dri->dri2->base.version >= 3) {
 __glXEnableExtension(screen->glx_enable_bits,
@@ -841,45 +838,27 @@ initializeExtensions(__GLXscreen * screen)
  "GLX_EXT_create_context_es_profile");
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_EXT_create_context_es2_profile");
-LogMessage(X_INFO, "AIGLX: enabled GLX_ARB_create_context\n");
-LogMessage(X_INFO, "AIGLX: enabled GLX_ARB_create_context_profile\n");
-LogMessage(X_INFO,
-   "AIGLX: enabled GLX_EXT_create_context_es{,2}_profile\n");
 }
 
 if (DRI2HasSwapControl(pScreen)) {
 __glXEnableExtension(screen->glx_enable_bits, "GLX_INTEL_swap_event");
 __glXEnableExtension(screen->glx_enable_bits, "GLX_SGI_swap_control");
-LogMessage(X_INFO, "AIGLX: enabled GLX_INTEL_swap_event\n");
-LogMessage(X_INFO, "AIGLX: enabled GLX_SGI_swap_control\n");
 }
 
 /* enable EXT_framebuffer_sRGB extension (even if there are no sRGB 
capable fbconfigs) */
-{
-__glXEnableExtension(screen->glx_enable_bits,
- "GLX_EXT_framebuffer_sRGB");
-LogMessage(X_INFO, "AIGLX: enabled GLX_EXT_framebuffer_sRGB\n");
-}
+__glXEnableExtension(screen->glx_enable_bits, "GLX_EXT_framebuffer_sRGB");
 
 /* enable ARB_fbconfig_float extension (even if there are no float 
fbconfigs) */
-{
-__glXEnableExtension(screen->glx_enable_bits, 
"GLX_ARB_fbconfig_float");
-LogMessage(X_INFO, "AIGLX: enabled GLX_ARB_fbconfig_float\n");
-}
+__glXEnableExtension(screen->glx_enable_bits, "GLX_ARB_fbconfig_float");
 
 /* enable EXT_fbconfig_packed_float (even if there are no packed float 
fbconfigs) */
-{
-__glXEnableExtension(screen->glx_enable_bits, 
"GLX_EXT_fbconfig_packed_float");
-LogMessage(X_INFO, "AIGLX: enabled GLX_EXT_fbconfig_packed_float\n");
-}
+__glXEnableExtension(screen->glx_enable_bits, 
"GLX_EXT_fbconfig_packed_float");
 
 for (i = 0; extensions[i]; i++) {
 if (strcmp(extensions[i]->name, __DRI_TEX_BUFFER) == 0) {
 dri->texBuffer = (const __DRItexBufferExtension *) extensions[i];
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_EXT_texture_from_pixmap");
-LogMessage(X_INFO,
-   "AIGLX: GLX_EXT_texture_from_pixmap backed by buffer 
objects\n");
 }
 
 if (strcmp(extensions[i]->name, __DRI2_FLUSH) == 0 &&
@@ -891,8 +870,6 @@ initializeExtensions(__GLXscreen * screen)
 dri->dri2->base.version >= 3) {
 __glXEnableExtension(screen->glx_enable_bits,
  "GLX_ARB_create_context_robustness");
-LogMessage(X_INFO,
-   "AIGLX: enabled GLX_ARB_create_context_robustness\n");
 }
 
 #ifdef __DRI2_FLUSH_CONTROL
diff --git a/glx/glxdriswrast.c b/glx/glxdriswrast.c
index adc97df93e..caad9a1fe7 100644
--- a/glx/glxdriswrast.c
+++ b/glx/glxdriswrast.c
@@ -351,10 +351,7 @@ initializeExtensions(__GLXscreen * screen)
 int i;
 
 __glXEnableExtension(screen->glx_enable_bits, "GLX_MESA_copy_sub_buffer");
-LogMessage(X_INFO, "IGLX: enabled GLX_MESA_copy_sub_buffer\n");
-
 __glXEnableExtension(screen->glx_enable_bits, "GLX_EXT_no_config_context");
-LogMessage(X_INFO, "IGLX: enabled GLX_EXT_no_config_context\n");
 
 if (dri->swrast->base.version >= 3) {
 __glXEnableExtension(screen->glx_enable_bits,
-- 
2.14.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: [PATCH xserver] os: Fix strtok/free crash in ComputeLocalClient

[Michel Dänzer]

On 2017-12-13 04:43 PM, Adam Jackson wrote:
> On Tue, 2017-12-12 at 22:18 +0100, Tomasz Śniatowski wrote:
>> On 8 December 2017 at 16:46, Michel Dänzer  wrote:
>>>
>>> Hmm. My initial answer was no, since ComputeLocalClient should only be
>>> called on the main thread. But if there can be a race with strtok
>>> getting called from other places, there might be an issue. Anyway,
>>> that's not something introduced by this patch but could be addressed in
>>> another patch. This patch is
>>>
>>> Reviewed-by: Michel Dänzer 
>>
>> Forgive my ignorance, am I supposed to do something now to get this merged?
> 
> Merged to master and 1.19 branch, thanks!

Thanks Adam, sorry, been busy with other stuff.


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

Re: [PATCH xserver 6/6] os: Remove unused OsRegisterSigWrapper

[Olivier Fourdan]

On Wed, Dec 13, 2017 at 5:15 PM, Adam Jackson  wrote:

> On Wed, 2017-12-13 at 16:21 +0100, Olivier Fourdan wrote:
>
> > Note that xf86-video-intel/src/sna/sna_accel.c makes use of
> > OsRegisterSigWrapper() and will need updating.
>
> Ngh. Okay, merged the other five, will defer this one until intel is
> updated.
>

For the record, this was added in 2013 with:

https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6ac1ac98

with a check for the correct xorg version (with the api)  from:

https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=693c1343



> remote: I: patch #189373 updated using rev 722c8035dcf3ae0b18841066fe4ee0
> 30277274bc.
> remote: I: patch #189376 updated using rev 0a255dceb79ee28a88667d5bd23cf9
> 89dbf9bed8.
> remote: I: patch #189374 updated using rev 9c72887939f319e185d2726d9d9a41
> 91b9d12efd.
> remote: E: failed to find patch for rev 4353d83f60766824a65f183716616e
> ee8e17bb24.
> remote: I: patch #189377 updated using rev bed28300999a07514d741abe5c748a
> df234e18a6.
> remote: I: 4 patch(es) updated to state Accepted.
> To ssh://git.freedesktop.org/git/xorg/xserver
>fe46cbea0f..bed2830099  master -> master
>

Cheers!

Olivier
___
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] meson: Add dependency on generated code fragments in hw/xwin/glx/

[Adam Jackson]

On Tue, 2017-10-10 at 13:43 +0100, Jon Turney wrote:
> Somehow I'd managed to write this with this dependency missing, so this only
> works correctly when the generated files already exist and the correct
> automatic dependencies generated, but fails on a clean build.
> 
> Including generated files with a .c extension into the sources for a target
> causes meson to want to compile them (and it seems to be hard to say "make
> the directory containing this generated file available to include").
> 
> So, change the extension of included generated C fragments to .ic
> 
> Update the autotools build to align.
> 
> Signed-off-by: Jon Turney 

remote: I: patch #181423 updated using rev 
3265d0c81f7a501258fa91e49fcc137714b4af5e.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   edda951fa5..3265d0c81f  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 xserver 1/2] os: Add epoll-like pollset implementation for AIX

[Adam Jackson]

On Thu, 2017-10-12 at 19:21 -0700, Keith Packard wrote:
> Peter Harris  writes:
> 
> > AIX's poll only allows FD_SETSIZE entries in the fd list, which is
> > insufficient for expanded MaxClients.
> 
> I can't evaluate whether these patches actually do the right thing, but
> they shouldn't affect systems which don't support the necessary
> functionality. I assume someone might review the Solaris patch, but is
> there anyone who can review the AIX patch?
> 
> For the pair:
> 
> Acked-by: Keith Packard 

Merged:

remote: I: patch #182226 updated using rev 
83c04ee6eae1edc80528203fb515425108171cd8.
remote: I: patch #182247 updated using rev 
edda951fa5145a50915611ee0e9e459074117700.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   bed2830099..edda951fa5  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 xserver 6/6] os: Remove unused OsRegisterSigWrapper

[Adam Jackson]

On Wed, 2017-12-13 at 16:21 +0100, Olivier Fourdan wrote:

> Note that xf86-video-intel/src/sna/sna_accel.c makes use of
> OsRegisterSigWrapper() and will need updating.

Ngh. Okay, merged the other five, will defer this one until intel is
updated.

remote: I: patch #189373 updated using rev 
722c8035dcf3ae0b18841066fe4ee030277274bc.
remote: I: patch #189376 updated using rev 
0a255dceb79ee28a88667d5bd23cf989dbf9bed8.
remote: I: patch #189374 updated using rev 
9c72887939f319e185d2726d9d9a4191b9d12efd.
remote: E: failed to find patch for rev 
4353d83f60766824a65f183716616eee8e17bb24.
remote: I: patch #189377 updated using rev 
bed28300999a07514d741abe5c748adf234e18a6.
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   fe46cbea0f..bed2830099  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

AW: monitor hotplug resolution switch

[Johann Obermayr]

Hello,

> -Ursprüngliche Nachricht-
> Von: xorg [mailto:xorg-boun...@lists.x.org] Im Auftrag von Felix Miata
> Gesendet: Mittwoch, 13. Dezember 2017 11:31
> An: xorg@lists.x.org
> Betreff: Re: monitor hotplug resolution switch
> 
> Johann Obermayr composed on 2017-12-13 08:36 (UTC:
> 
> >> Johann Obermayr composed:
> 
> >>> i have a x86 machine with i915 graphics.
> 
> >>> With connected display (1920x1080) all is ok.
> 
> >>> But if I disconnect the monitor, the resolution switch to 320x200.
> 
> >>> How can I disable this ?
> 
> >>> I will always have the same resolution (1920x1080)
> 
> >>> How can I do this ?
> 
> >> some more info is certainly necessary
> 
> >> what OS?
> >> what remaining monitor?
> 
> >> what do xrandr say?
> 
> > yes, sorry.
> > X86 dualcore Intel(R) Celeron(R) CPU G1820 @ 2.70GHz With On board
> > graphics i915
> 
> 'inxi -c0 -G' and/or 'lspci -nnk | grep -A4 VGA' would tell a bit more.

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell Integrated 
Graphics Controller [8086:0402] (rev 06)
Subsystem: Intel Corporation Haswell Integrated Graphics Controller 
[8086:0402]
Kernel driver in use: i915

> 
> > Older Yocto build with Kernel 3.10.0
> 
> That kernel version is older than your G1820 CPU.
> 
> > X.Org X Server 1.14.0
> > Release Date: 2013-03-05
> > [1274713.521] X Protocol Version 11, Revision 0 [1274713.521] Build
> > Operating System: Linux 3.2.0-126-generic-pae i686 [1274713.521]
> > Current Operating System: Linux sigmatek-x86-mp 3.10.0 #48 SMP
> PREEMPT Wed Dec 6 18:30:54 CET 2017 i686
> > [1274713.521] Current version of pixman: 0.29.2
> 
> Why did you omit the "Kernel command line:" line? What's on it might
> explain why falling back to 320x200, if the age of your hardware being newer
> than your software does not.
> 
> > And using xf86-video-intel-2.21.3.tar.bz2
> 
> That predates the release of your G1820 (Haswell) CPU by nearly a year.

Now i have compile version 2.99.917
This support virtual outputs. (with sna enabled)

Now I will make some test with this virtual outputs.

> 
> > xorg.conf
> ...
> > Section "Screen"
> > Identifier "Screen0"
> > Monitor"Monitor0"
> > DefaultDepth 16
> > SubSection "Display"
> > Viewport   0 0
> > Depth 16
> > EndSubSection
> > EndSection
> 
> > Yes we use 16 bit color depth.
> 
> That's not as well tested as the higher depths, and may cause inexplicable
> trouble.

I think intel will wrap this.
Because if I ask framebuffer, it tell me that he has 32bit color.
But only x-server will work with 16 bit.

> 
> > root@sigmatek-x86-mp:~# xrandr
> > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> > VGA1 disconnected
> > DP1 disconnected
> > HDMI1 disconnected
> > DP2 disconnected
> > HDMI2 disconnected
> > DP3 connected
> >1920x1080  60.0 +
> > HDMI3 disconnected
> 
> > But after disconnect the monitor, the driver will change resolution to
> 320x200.
> > But we will, that driver does not change the resolution. Or we can define
> the default resolution.
> 
> Section "Monitor"
> ...
>   Option  "PreferredMode" "1920x1080"
> ...
> EndSection
> 
> PreferredMode option should define resolution preferred, if the hardware is
> supported.
> --
> "Wisdom is supreme; therefore get wisdom. Whatever else you get, get
> wisdom." Proverbs 4:7 (New Living Translation)
> 
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata  ***  http://fm.no-ip.com/
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] xwayland: Give up “cleanly“ on Wayland socket errors

[Adam Jackson]

On Tue, 2017-11-21 at 14:45 +0100, Olivier Fourdan wrote:
> Xwayland is a pretty standard Wayland client, we want to be able to
> capture core dumps on crashes.
> 
> Yet using "-core" causes any FatalError() to generate a core dump,
> meaning that we would get a core file for all Wayland server crashes,
> which would generate a lot of false positives.
> 
> Instead of using FatalError() on Wayland socket errors, give up
> cleanly
> to avoid dumping core files when "-core" is used.
> 
> See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502
>  and: https://bugzilla.gnome.org/show_bug.cgi?id=789086
> 
> Signed-off-by: Olivier Fourdan 

remote: I: patch #189529 updated using rev 
fe46cbea0f19959d469ca4d1f09be379dc7b1e45.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   6883ae43eb..fe46cbea0f  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 xserver] os: Fix strtok/free crash in ComputeLocalClient

[Adam Jackson]

On Tue, 2017-12-12 at 22:18 +0100, Tomasz Śniatowski wrote:
> On 8 December 2017 at 16:46, Michel Dänzer  wrote:
> > 
> > Hmm. My initial answer was no, since ComputeLocalClient should only be
> > called on the main thread. But if there can be a race with strtok
> > getting called from other places, there might be an issue. Anyway,
> > that's not something introduced by this patch but could be addressed in
> > another patch. This patch is
> > 
> > Reviewed-by: Michel Dänzer 
> 
> Forgive my ignorance, am I supposed to do something now to get this merged?

Merged to master and 1.19 branch, thanks!

- 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 xserver 6/6] os: Remove unused OsRegisterSigWrapper

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> Signed-off-by: Adam Jackson 
> ---
>  include/os.h |  3 ---
>  os/osinit.c  | 19 ---
>  2 files changed, 22 deletions(-)
>
> diff --git a/include/os.h b/include/os.h
> index e141a6b02c..593c784753 100644
> --- a/include/os.h
> +++ b/include/os.h
> @@ -297,12 +297,9 @@ _X_ATTRIBUTE_PRINTF(1, 0)
>  _X_DEPRECATED;
>
>  typedef void (*OsSigHandlerPtr) (int /* sig */ );
> -typedef int (*OsSigWrapperPtr) (int /* sig */ );
>
>  extern _X_EXPORT OsSigHandlerPtr
>  OsSignal(int /* sig */ , OsSigHandlerPtr /* handler */ );
> -extern _X_EXPORT OsSigWrapperPtr
> -OsRegisterSigWrapper(OsSigWrapperPtr newWrap);
>
>  extern _X_EXPORT int auditTrailLevel;
>
> diff --git a/os/osinit.c b/os/osinit.c
> index 8575319fff..bf5b4b58af 100644
> --- a/os/osinit.c
> +++ b/os/osinit.c
> @@ -88,18 +88,6 @@ int limitNoFile = -1;
>  /* The actual user defined max number of clients */
>  int LimitClients = LIMITCLIENTS;
>
> -static OsSigWrapperPtr OsSigWrapper = NULL;
> -
> -OsSigWrapperPtr
> -OsRegisterSigWrapper(OsSigWrapperPtr newSigWrapper)
> -{
> -OsSigWrapperPtr oldSigWrapper = OsSigWrapper;
> -
> -OsSigWrapper = newSigWrapper;
> -
> -return oldSigWrapper;
> -}
> -
>  /*
>   * OsSigHandler --
>   *Catch unexpected signals and exit or continue cleanly.
> @@ -124,13 +112,6 @@ OsSigHandler(int signo)
>  }
>  #endif  /* RTLD_DI_SETSIGNAL */
>
> -if (OsSigWrapper != NULL) {
> -if (OsSigWrapper(signo) == 0) {
> -/* ddx handled signal and wants us to continue */
> -return;
> -}
> -}
> -
>  /* log, cleanup, and abort */
>  xorg_backtrace();
>
> --
> 2.14.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


Note that xf86-video-intel/src/sna/sna_accel.c makes use of
OsRegisterSigWrapper() and will need updating.

Anyway, LGTM.

Reviewed-by: Olivier Fourdan 
___
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 5/6] kdrive: remove KdSignalWrapper etc.

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> This no longer does anything useful.
>
> Signed-off-by: Adam Jackson 
> ---
>  hw/kdrive/src/kdrive.c | 14 --
>  1 file changed, 14 deletions(-)
>
> diff --git a/hw/kdrive/src/kdrive.c b/hw/kdrive/src/kdrive.c
> index 82dcf4ae73..6dbb908565 100644
> --- a/hw/kdrive/src/kdrive.c
> +++ b/hw/kdrive/src/kdrive.c
> @@ -86,8 +86,6 @@ const char *kdGlobalXkbLayout = NULL;
>  const char *kdGlobalXkbVariant = NULL;
>  const char *kdGlobalXkbOptions = NULL;
>
> -static Bool kdCaughtSignal = FALSE;
> -
>  void
>  KdDisableScreen(ScreenPtr pScreen)
>  {
> @@ -168,9 +166,6 @@ void
>  AbortDDX(enum ExitCode error)
>  {
>  KdDisableScreens();
> -
> -if (kdCaughtSignal)
> -OsAbort();
>  }
>
>  void
> @@ -937,13 +932,6 @@ KdAddScreen(ScreenInfo * pScreenInfo,
>  AddScreen(KdScreenInit, argc, argv);
>  }
>
> -static int
> -KdSignalWrapper(int signum)
> -{
> -kdCaughtSignal = TRUE;
> -return 1;   /* use generic OS layer cleanup & abort */
> -}
> -
>  void
>  KdInitOutput(ScreenInfo * pScreenInfo, int argc, char **argv)
>  {
> @@ -985,8 +973,6 @@ KdInitOutput(ScreenInfo * pScreenInfo, int argc, char
> **argv)
>  for (screen = card->screenList; screen; screen = screen->next)
>  KdAddScreen(pScreenInfo, screen, argc, argv);
>
> -OsRegisterSigWrapper(KdSignalWrapper);
> -
>  #if defined(CONFIG_UDEV) || defined(CONFIG_HAL)
>  if (SeatId) /* Enable input hot-plugging */
>  config_pre_init();
> --
> 2.14.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


LGTM.

Reviewed-by: Olivier Fourdan 
___
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 4/6] xfree86: remove xf86CaughtSignal etc.

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> This no longer does anything useful.
>
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/common/xf86.h|  2 --
>  hw/xfree86/common/xf86Events.c  | 11 ---
>  hw/xfree86/common/xf86Globals.c |  1 -
>  hw/xfree86/common/xf86Helper.c  |  6 --
>  hw/xfree86/common/xf86Init.c| 17 +++--
>  hw/xfree86/common/xf86Priv.h|  2 --
>  hw/xfree86/common/xf86Privstr.h |  1 -
>  hw/xfree86/doc/ddxDesign.xml| 10 --
>  8 files changed, 3 insertions(+), 47 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
> index 43b693143e..1c25468942 100644
> --- a/hw/xfree86/common/xf86.h
> +++ b/hw/xfree86/common/xf86.h
> @@ -296,8 +296,6 @@ xf86ServerIsResetting(void);
>  extern _X_EXPORT Bool
>  xf86ServerIsOnlyDetecting(void);
>  extern _X_EXPORT Bool
> -xf86CaughtSignal(void);
> -extern _X_EXPORT Bool
>  xf86GetVidModeAllowNonLocal(void);
>  extern _X_EXPORT Bool
>  xf86GetVidModeEnabled(void);
> diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/
> xf86Events.c
> index a27c7ff1b0..8a800bd8fd 100644
> --- a/hw/xfree86/common/xf86Events.c
> +++ b/hw/xfree86/common/xf86Events.c
> @@ -267,17 +267,6 @@ xf86RemoveEnabledDevice(InputInfoPtr pInfo)
>  InputThreadUnregisterDev(pInfo->fd);
>  }
>
> -/*
> - * xf86SigWrapper --
> - *Catch unexpected signals and exit or continue cleanly.
> - */
> -int
> -xf86SigWrapper(int signo)
> -{
> -xf86Info.caughtSignal = TRUE;
> -return 1;   /* abort */
> -}
> -
>  /*
>   * xf86PrintBacktrace --
>   *Print a stack backtrace for debugging purposes.
> diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/
> xf86Globals.c
> index ddf7a8696b..85efe3fc12 100644
> --- a/hw/xfree86/common/xf86Globals.c
> +++ b/hw/xfree86/common/xf86Globals.c
> @@ -107,7 +107,6 @@ xf86InfoRec xf86Info = {
>  .dontZap = FALSE,
>  .dontZoom = FALSE,
>  .notrapSignals = FALSE,
> -.caughtSignal = FALSE,
>  .currentScreen = NULL,
>  #ifdef CSRG_BASED
>  .consType = -1,
> diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/
> xf86Helper.c
> index 447ed3f8fe..393a7aa881 100644
> --- a/hw/xfree86/common/xf86Helper.c
> +++ b/hw/xfree86/common/xf86Helper.c
> @@ -1428,12 +1428,6 @@ xf86ServerIsOnlyDetecting(void)
>  return xf86DoConfigure;
>  }
>
> -Bool
> -xf86CaughtSignal(void)
> -{
> -return xf86Info.caughtSignal;
> -}
> -
>  Bool
>  xf86GetVidModeAllowNonLocal(void)
>  {
> diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
> index 994b63b430..57b38d07e7 100644
> --- a/hw/xfree86/common/xf86Init.c
> +++ b/hw/xfree86/common/xf86Init.c
> @@ -298,16 +298,9 @@ xf86PrivsElevated(void)
>  }
>
>  static void
> -InstallSignalHandlers(void)
> +TrapSignals(void)
>  {
> -/*
> - * Install signal handler for unexpected signals
> - */
> -xf86Info.caughtSignal = FALSE;
> -if (!xf86Info.notrapSignals) {
> -OsRegisterSigWrapper(xf86SigWrapper);
> -}
> -else {
> +if (xf86Info.notrapSignals) {
>  OsSignal(SIGSEGV, SIG_DFL);
>  OsSignal(SIGABRT, SIG_DFL);
>  OsSignal(SIGILL, SIG_DFL);
> @@ -423,7 +416,7 @@ InitOutput(ScreenInfo * pScreenInfo, int argc, char
> **argv)
>  }
>  }
>
> -InstallSignalHandlers();
> +TrapSignals();
>
>  /* Initialise the loader */
>  LoaderInit();
> @@ -960,10 +953,6 @@ ddxGiveUp(enum ExitCode error)
>  dbus_core_fini();
>
>  xf86CloseLog(error);
> -
> -/* If an unexpected signal was caught, dump a core for debugging */
> -if (xf86Info.caughtSignal)
> -OsAbort();
>  }
>
>  /*
> diff --git a/hw/xfree86/common/xf86Priv.h b/hw/xfree86/common/xf86Priv.h
> index 22bf5ff240..4fe2b5f336 100644
> --- a/hw/xfree86/common/xf86Priv.h
> +++ b/hw/xfree86/common/xf86Priv.h
> @@ -135,8 +135,6 @@ DoShowOptions(void)
>
>  extern _X_EXPORT void
>  xf86Wakeup(void *blockData, int err);
> -extern _X_HIDDEN int
> -xf86SigWrapper(int signo);
>  extern _X_EXPORT void
>  xf86HandlePMEvents(int fd, void *data);
>  extern _X_EXPORT int (*xf86PMGetEventFromOs) (int fd, pmEvent * events,
> diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/
> xf86Privstr.h
> index e4b479f4f9..c5048a3997 100644
> --- a/hw/xfree86/common/xf86Privstr.h
> +++ b/hw/xfree86/common/xf86Privstr.h
> @@ -64,7 +64,6 @@ typedef struct {
>  Bool dontZap;
>  Bool dontZoom;
>  Bool notrapSignals; /* don't exit cleanly - die at fault */
> -Bool caughtSignal;
>
>  /* graphics part */
>  ScreenPtr currentScreen;
> diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
> index 7579850267..13994f7a91 100644
> --- a/hw/xfree86/doc/ddxDesign.xml
> +++ b/hw/xfree86/doc/ddxDesign.xml
> @@ -2053,16 +2053,6 @@ functions is as follows:
>
> 
>
> -  
> - 
> -Bool xf86CaughtSignal();
> 

Re: [PATCH xserver 3/6] os: Make OsSignalHandler ask for core dumps for signo != SIGQUIT

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> SIGQUIT is a normal termination request, but any other signal we handle
> here wants a core. This has the effect of making FatalError's call to
> AbortServer trigger the
>
> if (CoreDump)
> OsAbort();
>
> path. This will allow us to remove some DDX code that has the same net
> effect.
>
> Signed-off-by: Adam Jackson 
> ---
>  os/osinit.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/os/osinit.c b/os/osinit.c
> index cd769d181c..8575319fff 100644
> --- a/os/osinit.c
> +++ b/os/osinit.c
> @@ -52,6 +52,7 @@ SOFTWARE.
>  #include 
>  #include "os.h"
>  #include "osdep.h"
> +#include "opaque.h"
>  #include 
>  #include 
>  #include 
> @@ -74,8 +75,6 @@ SOFTWARE.
>  #define ADMPATH "/usr/adm/X%smsgs"
>  #endif
>
> -extern char *display;
> -
>  #ifdef RLIMIT_DATA
>  int limitDataSpace = -1;
>  #endif
> @@ -151,6 +150,9 @@ OsSigHandler(int signo)
>  }
>  #endif
>
> +if (signo != SIGQUIT)
> +CoreDump = TRUE;
> +
>  FatalError("Caught signal %d (%s). Server aborting\n",
> signo, strsignal(signo));
>  }
> --
> 2.14.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


If we set Coredump to TRUE here for all signals but SIGQUIT, do we still
need the “-core” command line option?

Anyway, LGTM.

Reviewed-by: Olivier Fourdan 
___
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/6] xfree86: Remove xf86InterceptSignals

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> The only consumer of this is the Linux vm86 backend for int10 (which you
> should not use), and there all it serves to do is make signals generated
> by the vm86 task non-fatal. In practice this error appears never to
> happen, and marching ahead with root privileges after arbitrary code has
> raised a signal seems like a poor plan.
>
> Remove the usage in the vm86 code, making this error fatal.
>
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/common/xf86.h|  1 -
>  hw/xfree86/common/xf86Events.c  | 14 --
>  hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c | 13 +
>  3 files changed, 1 insertion(+), 27 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
> index db6e299b31..43b693143e 100644
> --- a/hw/xfree86/common/xf86.h
> +++ b/hw/xfree86/common/xf86.h
> @@ -215,7 +215,6 @@ extern _X_EXPORT void xf86DisableGeneralHandler(void
> *handler);
>  extern _X_EXPORT void xf86EnableGeneralHandler(void *handler);
>  extern _X_EXPORT InputHandlerProc xf86SetConsoleHandler(InputHandlerProc
>  handler, void
> *data);
> -extern _X_EXPORT void xf86InterceptSignals(int *signo);
>  extern _X_EXPORT void xf86ProcessActionEvent(ActionEvent action, void
> *arg);
>  extern _X_EXPORT void xf86PrintBacktrace(void);
>  extern _X_EXPORT Bool xf86VTOwner(void);
> diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/
> xf86Events.c
> index e2e6ca7691..a27c7ff1b0 100644
> --- a/hw/xfree86/common/xf86Events.c
> +++ b/hw/xfree86/common/xf86Events.c
> @@ -267,15 +267,6 @@ xf86RemoveEnabledDevice(InputInfoPtr pInfo)
>  InputThreadUnregisterDev(pInfo->fd);
>  }
>
> -static int *xf86SignalIntercept = NULL;
> -
> -void
> -xf86InterceptSignals(int *signo)
> -{
> -if ((xf86SignalIntercept = signo))
> -*signo = -1;
> -}
> -
>  /*
>   * xf86SigWrapper --
>   *Catch unexpected signals and exit or continue cleanly.
> @@ -283,11 +274,6 @@ xf86InterceptSignals(int *signo)
>  int
>  xf86SigWrapper(int signo)
>  {
> -if (xf86SignalIntercept && (*xf86SignalIntercept < 0)) {
> -*xf86SignalIntercept = signo;
> -return 0;   /* continue */
> -}
> -
>  xf86Info.caughtSignal = TRUE;
>  return 1;   /* abort */
>  }
> diff --git a/hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c
> b/hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c
> index 1876983991..134809814f 100644
> --- a/hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c
> +++ b/hw/xfree86/os-support/linux/int10/vm86/linux_vm86.c
> @@ -231,20 +231,9 @@ vm86_GP_fault(xf86Int10InfoPtr pInt)
>  static int
>  do_vm86(xf86Int10InfoPtr pInt)
>  {
> -int retval, signo;
> +int retval;
>
> -xf86InterceptSignals();
>  retval = vm86_rep(VM86S);
> -xf86InterceptSignals(NULL);
> -
> -if (signo >= 0) {
> -xf86DrvMsg(pInt->pScrn->scrnIndex, X_ERROR,
> -   "vm86() syscall generated signal %d.\n", signo);
> -dump_registers(pInt);
> -dump_code(pInt);
> -stack_trace(pInt);
> -return 0;
> -}
>
>  switch (VM86_TYPE(retval)) {
>  case VM86_UNKNOWN:
> --
> 2.14.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


I can't tell whether or not this happens in practice, but for the code
part, this is:

Reviewed-by: Olivier Fourdan 
___
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/6] xfree86: Remove xf86InterceptSigIll

[Olivier Fourdan]

On Mon, Nov 20, 2017 at 9:43 PM, Adam Jackson  wrote:

> This was added in ~2004 for the sis driver, to detect whether it could
> use SSE for memcpy. Charmingly, the code to check whether that feature
> exists in the server is:
>
> #if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(6,8,99,13,0)
> #define SISCHECKOSSSE   /* Automatic check OS for SSE;
> requires SigIll facility */
> #endif
>
> Which means it has never worked in any modular server release.
>
> A less gross way to do this is to check for SSE support with getauxval()
> or /proc/cpuinfo or similar. Since no driver is using the existing
> intercept mechanism, drop it.
>
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/common/xf86.h   |  1 -
>  hw/xfree86/common/xf86Events.c | 13 -
>  2 files changed, 14 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86.h b/hw/xfree86/common/xf86.h
> index 674e83cb1f..db6e299b31 100644
> --- a/hw/xfree86/common/xf86.h
> +++ b/hw/xfree86/common/xf86.h
> @@ -216,7 +216,6 @@ extern _X_EXPORT void xf86EnableGeneralHandler(void
> *handler);
>  extern _X_EXPORT InputHandlerProc xf86SetConsoleHandler(InputHandlerProc
>  handler, void
> *data);
>  extern _X_EXPORT void xf86InterceptSignals(int *signo);
> -extern _X_EXPORT void xf86InterceptSigIll(void (*sigillhandler) (void));
>  extern _X_EXPORT void xf86ProcessActionEvent(ActionEvent action, void
> *arg);
>  extern _X_EXPORT void xf86PrintBacktrace(void);
>  extern _X_EXPORT Bool xf86VTOwner(void);
> diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events
> .c
> index 53ec74f261..e2e6ca7691 100644
> --- a/hw/xfree86/common/xf86Events.c
> +++ b/hw/xfree86/common/xf86Events.c
> @@ -276,14 +276,6 @@ xf86InterceptSignals(int *signo)
>  *signo = -1;
>  }
>
> -static void (*xf86SigIllHandler) (void) = NULL;
> -
> -void
> -xf86InterceptSigIll(void (*sigillhandler) (void))
> -{
> -xf86SigIllHandler = sigillhandler;
> -}
> -
>  /*
>   * xf86SigWrapper --
>   *Catch unexpected signals and exit or continue cleanly.
> @@ -291,11 +283,6 @@ xf86InterceptSigIll(void (*sigillhandler) (void))
>  int
>  xf86SigWrapper(int signo)
>  {
> -if ((signo == SIGILL) && xf86SigIllHandler) {
> -(*xf86SigIllHandler) ();
> -return 0;   /* continue */
> -}
> -
>  if (xf86SignalIntercept && (*xf86SignalIntercept < 0)) {
>  *xf86SignalIntercept = signo;
>  return 0;   /* continue */
> --
> 2.14.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


FWIW, I am not an expert of the xfree86 codebase, but if nobody uses that
then good riddance!

Reviewed-by: Olivier Fourdan 
___
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: monitor hotplug resolution switch

[Adam Jackson]

On Tue, 2017-12-12 at 11:22 +, Johann Obermayr wrote:
> Hello,
>  
> i have a x86 machine with i915 graphics.
> With connected display (1920x1080) all is ok.
> But if I disconnect the monitor, the resolution switch to 320x200.
>  
> How can I disable this ?

The X server does not resize anything on its own, only when a client
tells it to. Figure out what part of your desktop environment is
responsible for screen configuration, and tell it to stop resizing the
desktop just because the monitor went away.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: monitor hotplug resolution switch

[Felix Miata]

Johann Obermayr composed on 2017-12-13 08:36 (UTC:

>> Johann Obermayr composed:

>>> i have a x86 machine with i915 graphics.

>>> With connected display (1920x1080) all is ok.

>>> But if I disconnect the monitor, the resolution switch to 320x200.

>>> How can I disable this ?

>>> I will always have the same resolution (1920x1080)

>>> How can I do this ?

>> some more info is certainly necessary

>> what OS?
>> what remaining monitor?

>> what do xrandr say?

> yes, sorry.
> X86 dualcore Intel(R) Celeron(R) CPU G1820 @ 2.70GHz
> With On board graphics i915

'inxi -c0 -G' and/or 'lspci -nnk | grep -A4 VGA' would tell a bit more.

> Older Yocto build with Kernel 3.10.0

That kernel version is older than your G1820 CPU.

> X.Org X Server 1.14.0
> Release Date: 2013-03-05
> [1274713.521] X Protocol Version 11, Revision 0
> [1274713.521] Build Operating System: Linux 3.2.0-126-generic-pae i686
> [1274713.521] Current Operating System: Linux sigmatek-x86-mp 3.10.0 #48 SMP 
> PREEMPT Wed Dec 6 18:30:54 CET 2017 i686
> [1274713.521] Current version of pixman: 0.29.2 

Why did you omit the "Kernel command line:" line? What's on it might explain why
falling back to 320x200, if the age of your hardware being newer than your
software does not.

> And using xf86-video-intel-2.21.3.tar.bz2

That predates the release of your G1820 (Haswell) CPU by nearly a year.

> xorg.conf
...
> Section "Screen"
>   Identifier "Screen0"
>   Monitor"Monitor0"
>   DefaultDepth 16
>   SubSection "Display"
>   Viewport   0 0
>   Depth 16
>   EndSubSection
> EndSection

> Yes we use 16 bit color depth.   

That's not as well tested as the higher depths, and may cause inexplicable 
trouble.

> root@sigmatek-x86-mp:~# xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
> VGA1 disconnected
> DP1 disconnected
> HDMI1 disconnected
> DP2 disconnected
> HDMI2 disconnected
> DP3 connected
>1920x1080  60.0 +
> HDMI3 disconnected

> But after disconnect the monitor, the driver will change resolution to 
> 320x200.
> But we will, that driver does not change the resolution. Or we can define the 
> default resolution. 

Section "Monitor"
...
Option  "PreferredMode" "1920x1080"
...
EndSection

PreferredMode option should define resolution preferred, if the hardware is
supported.
-- 
"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xserver] os: Fix strtok/free crash in ComputeLocalClient

[Tomasz Śniatowski]

On 8 December 2017 at 16:46, Michel Dänzer  wrote:
> On 2017-12-07 11:19 AM, walter harms wrote:
>> Am 06.12.2017 12:16, schrieb Tomasz Śniatowski:
>>> Don't reuse cmd for strtok output to ensure the proper pointer is
>>> freed afterwards.
>>>
>>> The code incorrectly assumed the pointer returned by strtok(cmd, ":")
>>> would always point to cmd. However, strtok(str, sep) != str if str
>>> begins with sep. This caused an invalid-free crash when running
>>> a program under X with a name beginning with a colon.
>>>
>>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=104123
>>>
>>
>> Yes, strtok returns a pointer to its arguments.
>> btw: strtok is not thread-safe, could that be an issue with that function ?

Not really -- the crash I'm getting is 100% reproducible with no races
or thread issues in sight. Equivalent crash call stacks can be obtained
in a toy program that does a
free(strtok(strdup(":a"), ":");
which is the same incorrect use of strtok's return value in free.

> Hmm. My initial answer was no, since ComputeLocalClient should only be
> called on the main thread. But if there can be a race with strtok
> getting called from other places, there might be an issue. Anyway,
> that's not something introduced by this patch but could be addressed in
> another patch. This patch is
>
> Reviewed-by: Michel Dänzer 

Forgive my ignorance, am I supposed to do something now to get this merged?

>>> Signed-off-by: Tomasz Śniatowski 
>>> ---
>>>  os/access.c | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/os/access.c b/os/access.c
>>> index 8828e0834..97246160c 100644
>>> --- a/os/access.c
>>> +++ b/os/access.c
>>> @@ -1137,12 +1137,12 @@ ComputeLocalClient(ClientPtr client)
>>>  /* Cut off any colon and whatever comes after it, see
>>>   * 
>>> https://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html
>>>   */
>>> -cmd = strtok(cmd, ":");
>>> +char *tok = strtok(cmd, ":");
>>>
>>>  #if !defined(WIN32) || defined(__CYGWIN__)
>>> -ret = strcmp(basename(cmd), "ssh") != 0;
>>> +ret = strcmp(basename(tok), "ssh") != 0;
>>>  #else
>>> -ret = strcmp(cmd, "ssh") != 0;
>>> +ret = strcmp(tok, "ssh") != 0;
>>>  #endif
>>>
>>>  free(cmd);
>> ___
>> 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
>>
>
>
> --
> 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

Re: AW: monitor hotplug resolution switch

[j...@dodin.org]

Le 13/12/2017 à 09:36, Johann Obermayr a écrit :


root@sigmatek-x86-mp:~# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA1 disconnected
DP1 disconnected
HDMI1 disconnected
DP2 disconnected
HDMI2 disconnected
DP3 connected
1920x1080  60.0 +
HDMI3 disconnected


But after disconnect the monitor, the driver will change resolution to 320x200.
But we will, that driver does not change the resolution. Or we can define the 
default resolution.



what mean "default resolution" if no monitor is connected?

seems it's simply the lower resolution available

do you need some remote X?

you can play with xrandr

http://dodin.org/wiki/pmwiki.php?n=Doc.AddXResolution

but with no monitor I dunno what happen nor what is the config for 
remote X desktop


jdd


--
http://dodin.org
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

AW: monitor hotplug resolution switch

[Johann Obermayr]

> -Ursprüngliche Nachricht-
> Von: xorg [mailto:xorg-boun...@lists.x.org] Im Auftrag von j...@dodin.org
> Gesendet: Dienstag, 12. Dezember 2017 23:30
> An: xorg@lists.x.org
> Betreff: Re: monitor hotplug resolution switch
> 
> Le 12/12/2017 à 12:22, Johann Obermayr a écrit :
> > Hello,
> >
> > i have a x86 machine with i915 graphics.
> >
> > With connected display (1920x1080) all is ok.
> >
> > But if I disconnect the monitor, the resolution switch to 320x200.
> >
> > How can I disable this ?
> >
> > I will always have the same resolution (1920x1080)
> >
> > How can I do this ?
> >
> some more info is certainly necessary
> 
> what OS?
> what remaining monitor?
> 
> what do xrandr say?
> 
> thanks
> jdd
> 
> --
> http://dodin.org
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s


Hello,

yes, sorry.
X86 dualcore Intel(R) Celeron(R) CPU G1820 @ 2.70GHz
With On board graphics i915

Older Yocto build with Kernel 3.10.0
X.Org X Server 1.14.0
Release Date: 2013-03-05
[1274713.521] X Protocol Version 11, Revision 0
[1274713.521] Build Operating System: Linux 3.2.0-126-generic-pae i686
[1274713.521] Current Operating System: Linux sigmatek-x86-mp 3.10.0 #48 SMP 
PREEMPT Wed Dec 6 18:30:54 CET 2017 i686
[1274713.521] Current version of pixman: 0.29.2
[1274713.521] (II) Module ABI versions:
[1274713.521]   X.Org ANSI C Emulation: 0.4
[1274713.521]   X.Org Video Driver: 14.1
[1274713.521]   X.Org XInput driver : 19.1
[1274713.521]   X.Org Server Extension : 7.0
And using xf86-video-intel-2.21.3.tar.bz2

xorg.conf

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 0
EndSection

Section "ServerFlags"
Option "BlankTime"  "0"
Option "StandbyTime"  "0"
Option "SuspendTime"  "0"
Option "OffTime"  "0"
EndSection

Section "Screen"
Identifier "Screen0"
Monitor"Monitor0"
DefaultDepth 16
SubSection "Display"
Viewport   0 0
Depth 16
EndSubSection
EndSection

Yes we use 16 bit color depth.

root@sigmatek-x86-mp:~# xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
VGA1 disconnected
DP1 disconnected
HDMI1 disconnected
DP2 disconnected
HDMI2 disconnected
DP3 connected
   1920x1080  60.0 +
HDMI3 disconnected


But after disconnect the monitor, the driver will change resolution to 320x200.
But we will, that driver does not change the resolution. Or we can define the 
default resolution.

Thanks
  Johann
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s