[PATCH v2 xserver] os,dix: apply libs relocation unconditionally
When building with DTrace compiler enabled, "ld -r" is applied to the
entire os/ and dix/, making their symbols visible from everywhere on
linker command line. This alters the build:
- 3f8c2f94483bf0b96e129c97ef4950170a3f05b4 was only necessary without dtrace.
- 3ef16dfb9830bd6b41ae428f4f213ae0c35c1056 fixed the with-dtrace, but broke
the without-dtrace dmx build.
The purpose of "-r" is to satisfy linker on Solaris that needs DTrace
objects to be put into a Relocatable Object.
Use the flag for non-DTrace build too.
v2: Also change noinst_PROGRAMS -> all-local to prevent revealed automake
warning:
os/Makefile.am:70: warning: deprecated feature: target 'os.O' overrides
'os.O$(EXEEXT)'
os/Makefile.am:70: change your target to read 'os.O$(EXEEXT)'
/usr/share/automake-1.15/am/program.am: target 'os.O$(EXEEXT)' was defined
here
os/Makefile.am:2: while processing program 'os.O'
Rebase upon fde5cd78 ("tests: Fix guards for ld -wrap") to be safe (no
change).
Reword.
Fixes "./configure --enable-dmx --with-dtrace=no" build.
Reported-by: Byeong-ryeol Kim
Fixes: 3ef16dfb ("dmx: fix linking")
Fixes: 49a26681 ("Add DTrace probe points")
Signed-off-by: Mihail Konev
---
configure.ac| 9 ++---
dix/Makefile.am | 11 ++-
os/Makefile.am | 13 +++--
3 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3bc15a81a263..f583a4b2f7d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1577,13 +1577,8 @@ AC_DEFINE(XSYNC, 1, [Support XSync extension])
AC_DEFINE(XCMISC, 1, [Support XCMisc extension])
AC_DEFINE(BIGREQS, 1, [Support BigRequests extension])
-if test "x$SPECIAL_DTRACE_OBJECTS" = "xyes" ; then
- DIX_LIB='$(top_builddir)/dix/dix.O'
- OS_LIB='$(top_builddir)/os/os.O $(SHA1_LIBS) $(DLOPEN_LIBS)
$(LIBUNWIND_LIBS)'
-else
- DIX_LIB='$(top_builddir)/dix/libdix.la'
- OS_LIB='$(top_builddir)/os/libos.la'
-fi
+DIX_LIB='$(top_builddir)/dix/dix.O'
+OS_LIB='$(top_builddir)/os/os.O $(SHA1_LIBS) $(DLOPEN_LIBS) $(LIBUNWIND_LIBS)'
AC_SUBST([DIX_LIB])
AC_SUBST([OS_LIB])
diff --git a/dix/Makefile.am b/dix/Makefile.am
index a4171d7e1f12..2e6de79b9f7f 100644
--- a/dix/Makefile.am
+++ b/dix/Makefile.am
@@ -1,4 +1,5 @@
noinst_LTLIBRARIES = libdix.la libmain.la
+all-local: dix.O
AM_CPPFLAGS = -I$(top_srcdir)/include
AM_CFLAGS = $(DIX_CFLAGS)
@@ -59,16 +60,16 @@ Xserver-dtrace.h: $(srcdir)/Xserver.d
endif
+DTRACE_OBJS =
if SPECIAL_DTRACE_OBJECTS
# Generate dtrace object code for probes in libdix
dtrace-dix.o: $(top_srcdir)/dix/Xserver.d libdix.la
$(AM_V_GEN)$(DTRACE) -G -C -o $@ -s $(top_srcdir)/dix/Xserver.d
$(am_libdix_la_OBJECTS:%.lo=.libs/%.o)
+DTRACE_OBJS += dtrace-dix.o
+endif
-noinst_PROGRAMS = dix.O
-
-dix_O_SOURCES =
-dix.O: dtrace-dix.o libdix.la
+# "ld -r" is required for Solaris
+dix.O: $(DTRACE_OBJS) libdix.la
$(AM_V_GEN)ld -r -o $@ $(am_libdix_la_OBJECTS:%.lo=.libs/%.o)
-endif
CLEANFILES = Xserver-dtrace.h
diff --git a/os/Makefile.am b/os/Makefile.am
index c6e78cb99fd5..9e5c7d696016 100644
--- a/os/Makefile.am
+++ b/os/Makefile.am
@@ -1,4 +1,5 @@
noinst_LTLIBRARIES = libos.la
+all-local: os.O
AM_CFLAGS = $(DIX_CFLAGS) $(SHA1_CFLAGS)
@@ -56,14 +57,14 @@ endif
EXTRA_DIST = $(SECURERPC_SRCS) $(XDMCP_SRCS)
+DTRACE_OBJS =
if SPECIAL_DTRACE_OBJECTS
# Generate dtrace object code for probes in libos & libdix
dtrace.o: $(top_srcdir)/dix/Xserver.d libos.la
$(AM_V_GEN)$(DTRACE) -G -C -o $@ -s $(top_srcdir)/dix/Xserver.d
.libs/*.o ../dix/.libs/*.o
-
-noinst_PROGRAMS = os.O
-
-os_O_SOURCES =
-os.O: dtrace.o libos.la
- $(AM_V_GEN)ld -r -o $@ dtrace.o .libs/*.o
+DTRACE_OBJS += dtrace.o
endif
+
+# "ld -r" is required for Solaris
+os.O: $(DTRACE_OBJS) libos.la
+ $(AM_V_GEN)ld -r -o $@ $(DTRACE_OBJS) .libs/*.o
--
2.9.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v3 xserver] os,dix: apply libs relocation unconditionally
When building with DTrace compiler enabled, "ld -r" is applied to the
entire os/ and dix/, making their symbols visible from everywhere on
linker command line. This alters the build:
- 3f8c2f94483bf0b96e129c97ef4950170a3f05b4 was only necessary without dtrace.
- 3ef16dfb9830bd6b41ae428f4f213ae0c35c1056 fixed the with-dtrace, but broke
the without-dtrace dmx build.
The purpose of "-r" is to satisfy linker on Solaris that needs DTrace
objects to be put into a Relocatable Object.
Use the flag for non-DTrace build too.
v2: Also change noinst_PROGRAMS -> all-local to prevent revealed automake
warning:
os/Makefile.am:70: warning: deprecated feature: target 'os.O' overrides
'os.O$(EXEEXT)'
os/Makefile.am:70: change your target to read 'os.O$(EXEEXT)'
/usr/share/automake-1.15/am/program.am: target 'os.O$(EXEEXT)' was defined
here
os/Makefile.am:2: while processing program 'os.O'
Rebase upon fde5cd78 ("tests: Fix guards for ld -wrap") to be safe (no
change).
Reword.
v3: Add all-local to CLEANFILES
Fixes "./configure --enable-dmx --with-dtrace=no" build.
Reported-by: Byeong-ryeol Kim
Fixes: 3ef16dfb ("dmx: fix linking")
Fixes: 49a26681 ("Add DTrace probe points")
Signed-off-by: Mihail Konev
---
configure.ac| 9 ++---
dix/Makefile.am | 13 +++--
os/Makefile.am | 13 -
3 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3bc15a81a263..f583a4b2f7d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1577,13 +1577,8 @@ AC_DEFINE(XSYNC, 1, [Support XSync extension])
AC_DEFINE(XCMISC, 1, [Support XCMisc extension])
AC_DEFINE(BIGREQS, 1, [Support BigRequests extension])
-if test "x$SPECIAL_DTRACE_OBJECTS" = "xyes" ; then
- DIX_LIB='$(top_builddir)/dix/dix.O'
- OS_LIB='$(top_builddir)/os/os.O $(SHA1_LIBS) $(DLOPEN_LIBS)
$(LIBUNWIND_LIBS)'
-else
- DIX_LIB='$(top_builddir)/dix/libdix.la'
- OS_LIB='$(top_builddir)/os/libos.la'
-fi
+DIX_LIB='$(top_builddir)/dix/dix.O'
+OS_LIB='$(top_builddir)/os/os.O $(SHA1_LIBS) $(DLOPEN_LIBS) $(LIBUNWIND_LIBS)'
AC_SUBST([DIX_LIB])
AC_SUBST([OS_LIB])
diff --git a/dix/Makefile.am b/dix/Makefile.am
index a4171d7e1f12..ed443a0cb2cb 100644
--- a/dix/Makefile.am
+++ b/dix/Makefile.am
@@ -1,4 +1,5 @@
noinst_LTLIBRARIES = libdix.la libmain.la
+all-local: dix.O
AM_CPPFLAGS = -I$(top_srcdir)/include
AM_CFLAGS = $(DIX_CFLAGS)
@@ -59,16 +60,16 @@ Xserver-dtrace.h: $(srcdir)/Xserver.d
endif
+DTRACE_OBJS =
if SPECIAL_DTRACE_OBJECTS
# Generate dtrace object code for probes in libdix
dtrace-dix.o: $(top_srcdir)/dix/Xserver.d libdix.la
$(AM_V_GEN)$(DTRACE) -G -C -o $@ -s $(top_srcdir)/dix/Xserver.d
$(am_libdix_la_OBJECTS:%.lo=.libs/%.o)
+DTRACE_OBJS += dtrace-dix.o
+endif
-noinst_PROGRAMS = dix.O
-
-dix_O_SOURCES =
-dix.O: dtrace-dix.o libdix.la
+# "ld -r" is required for Solaris
+dix.O: $(DTRACE_OBJS) libdix.la
$(AM_V_GEN)ld -r -o $@ $(am_libdix_la_OBJECTS:%.lo=.libs/%.o)
-endif
-CLEANFILES = Xserver-dtrace.h
+CLEANFILES = Xserver-dtrace.h dix.O
diff --git a/os/Makefile.am b/os/Makefile.am
index c6e78cb99fd5..1ef5083c78e1 100644
--- a/os/Makefile.am
+++ b/os/Makefile.am
@@ -1,4 +1,5 @@
noinst_LTLIBRARIES = libos.la
+all-local: os.O
AM_CFLAGS = $(DIX_CFLAGS) $(SHA1_CFLAGS)
@@ -56,14 +57,16 @@ endif
EXTRA_DIST = $(SECURERPC_SRCS) $(XDMCP_SRCS)
+DTRACE_OBJS =
if SPECIAL_DTRACE_OBJECTS
# Generate dtrace object code for probes in libos & libdix
dtrace.o: $(top_srcdir)/dix/Xserver.d libos.la
$(AM_V_GEN)$(DTRACE) -G -C -o $@ -s $(top_srcdir)/dix/Xserver.d
.libs/*.o ../dix/.libs/*.o
+DTRACE_OBJS += dtrace.o
+endif
-noinst_PROGRAMS = os.O
+# "ld -r" is required for Solaris
+os.O: $(DTRACE_OBJS) libos.la
+ $(AM_V_GEN)ld -r -o $@ $(DTRACE_OBJS) .libs/*.o
-os_O_SOURCES =
-os.O: dtrace.o libos.la
- $(AM_V_GEN)ld -r -o $@ dtrace.o .libs/*.o
-endif
+CLEANFILES = os.O
--
2.9.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v7 libX11] Compose sequences for rouble sign
Cyrillic combinations mirror the Qwerty-Jcuken keyboard layout. Add also sequences for hryvnia sign. Un-clash the dead_currency screwed up (me) in d9e340613077. Submitted-by: Victor V. Kustov Build-tested-by: Jon Turney Signed-off-by: Mihail Konev --- nls/en_US.UTF-8/Compose.pre | 14 ++ 1 file changed, 14 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index adc24fb5b5c2..1c580c9da4c8 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -190,6 +190,14 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN +: "₽" U20bd # ROUBLE SIGN +: "₽" U20bd # ROUBLE SIGN +: "₽" U20bd # ROUBLE SIGN +: "₽" U20bd # ROUBLE SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN @@ -203,6 +211,8 @@ XCOMM "₵" U20b5 CEDI SIGN : "₹" U20b9 # INDIAN RUPEE SIGN : "₹" U20b9 # INDIAN RUPEE SIGN : "₹" U20b9 # INDIAN RUPEE SIGN + <2> : "₴" U20b4 # HRYVNIA SIGN + <2>: "₴" U20b4 # HRYVNIA SIGN : "¢" cent # CENT SIGN : "¢" cent # CENT SIGN @@ -5315,6 +5325,10 @@ XCOMM : "₩" WonSign # WON SIGN : "円" U5186 # YEN : "¥" yen # YEN SIGN +: "₴" U20b4 # HRYVNIA SIGN +: "₴" U20b4 # HRYVNIA SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN : "¤" currency# CURRENCY SIGN : "¤" currency# CURRENCY SIGN : "¤" currency# CURRENCY SIGN -- 2.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC libX11 2/2] nls: Verify Compose at build
Signed-off-by: Mihail Konev --- nls/Makefile.am | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/nls/Makefile.am b/nls/Makefile.am index 57665fff4282..c0f0d0c7181f 100644 --- a/nls/Makefile.am +++ b/nls/Makefile.am @@ -24,7 +24,7 @@ locale.alias: locale.alias.pre < locale.alias.l1 > locale.alias.l2 cat locale.alias.l2 locale.alias.l1 > locale.alias -compose.dir: compose.dir.pre +compose.dir: compose.dir.pre compose-check $(AM_V_GEN)$(RAWCPP) $(RAWCPPFLAGS) $(CPP_FILES_FLAGS) < $(srcdir)/compose.dir.pre | $(CPP_SED_MAGIC) > compose.dir.l1 $(SED) -e '/^[^#][^ ]*:/s/://' -e '/^[^#].*[].*:/d' \ < compose.dir.l1 > compose.dir.l2 @@ -36,12 +36,6 @@ locale.dir: locale.dir.pre < locale.dir.l1 > locale.dir.l2 cat locale.dir.l2 locale.dir.l1 > locale.dir -if HAVE_PERL -LOG_COMPILER = $(PERL) -TESTS = compose-check.pl -endif HAVE_PERL - - # Per-locale data files XI18N_FILES = $(locales:%=%/XI18N_OBJS) @@ -54,3 +48,13 @@ nobase_x11locale_DATA = $(XLC_FILES) $(COMPOSE_FILES) EXTRA_DIST += $(nobase_x11locale_DATA:%=%.pre) CLEANFILES += $(nobase_x11locale_DATA) +# Checks for per-locale data files + +compose-check: $(COMPOSE_FILES) +if HAVE_PERL + @ $(PERL) $(srcdir)/compose-check.pl +else !HAVE_PERL + @: +endif !HAVE_PERL + +.PHONY: compose-check -- 2.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC libX11 1/2] nls: Factor out the lists of locale files
Signed-off-by: Mihail Konev --- nls/Makefile.am | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/nls/Makefile.am b/nls/Makefile.am index 0c544f6cf88f..57665fff4282 100644 --- a/nls/Makefile.am +++ b/nls/Makefile.am @@ -44,9 +44,13 @@ endif HAVE_PERL # Per-locale data files -nobase_dist_x11locale_DATA = $(locales:%=%/XI18N_OBJS) +XI18N_FILES = $(locales:%=%/XI18N_OBJS) +COMPOSE_FILES = $(locales:%=%/Compose) +XLC_FILES = $(locales:%=%/XLC_LOCALE) + +nobase_dist_x11locale_DATA = $(XI18N_FILES) +nobase_x11locale_DATA = $(XLC_FILES) $(COMPOSE_FILES) -nobase_x11locale_DATA = $(locales:%=%/XLC_LOCALE) $(locales:%=%/Compose) EXTRA_DIST += $(nobase_x11locale_DATA:%=%.pre) CLEANFILES += $(nobase_x11locale_DATA) -- 2.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC libX11 0/2] Verify Compose at build
This performs verification "on change", and prints errors out. Before, it was "make check; cat nls/test-suite.log". Mihail Konev (2): nls: Factor out the lists of locale files nls: Verify Compose at build nls/Makefile.am | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) -- 2.9.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Daniel Vetter writes: > On that, I think we could just unconditionally hand leases all encoders. > Encoders turned out to be a bit an uapi mistake. Well, given the complexity of hardware these days, even crtcs would probably best have been hidden... > Neither setcrtc nor atomic use it, the kernel always selects the right > encoder for you. It's only exposed to give userspace some hints wrt > routing (and it's pretty bad at describing modern restrictions, which > often means you get a 1:1 encoder/connector mapping). Unconditionally > exposing all encoders for all lessees would fix all these troubles. Yeah, I can't find encoders passed into any kernel api, other than the getencoder call. It seems like we can leave them as shared objects not subject to leasing as they are query-only. I'll go ahead and do that. The encoder crtc set still needs to be filtered in the query operation so that the client knows which crtc to use for each output. Now as to how we report the kernel objects that have been leased, we have two options: 1) Report them back via the X protocol 2) Have the client query the resulting lease for its contents I already suggested that the drm query API should be changed to report both type and id for each leased object, that would make it sufficient here. Instead of duplicating that over the X protocol, I suggest we just use the adjusted kernel API. > Note that there's also no properties on encoders, those only exist on > crtc, connector and planes. Any thoughts on access control for properties? Right now, the set property ioctl checks for access to the containing object, but there's no check when querying properties. This means that you don't need to add leases on properties. > Kinda more a comment on the kernel side than for xrandr. It's all tied together :-) -- -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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Daniel Vetter writes: > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: >> Manasi Navare writes: >> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: >> >> Manasi Navare writes: >> >> >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: >> >> >> Martin Peres writes: >> >> >> >> >> >> > On 26/01/17 14:37, Martin Peres wrote: >> >> >> >> Despite all the careful planing of the kernel, a link may become >> >> >> >> insufficient to handle the currently-set mode. At this point, the >> >> >> >> kernel should mark this particular configuration as being broken >> >> >> >> and potentially prune the mode before setting the offending >> >> >> >> connector's >> >> >> >> link-status to BAD and send the userspace a hotplug event. This may >> >> >> >> happen right after a modeset or later on. >> >> >> >> >> >> >> >> When available, we should use the link-status information to reset >> >> >> >> the wanted mode. >> >> >> >> >> >> >> >> Signed-off-by: Martin Peres >> >> >> > >> >> >> > The relevant kernel patches have landed in drm-tip about a month ago. >> >> >> > >> >> >> > Eric, would you mind providing feedback on or merging this patch? >> >> >> >> >> >> The later discussion has sounded like the kernel will (always) prune >> >> >> the >> >> >> mode when we re-query, meaning that it doesn't make any sense to try to >> >> >> re-set to the old mode. Is this not the case? >> >> > >> >> > >> >> > No the kernel will simply send a hotplug with link status as bad >> >> > and then after that point its userspace driver's responsibility >> >> > to check if link status is BAD, retry the same mode and if it fails >> >> > then re probe. >> >> >> >> So the kernel will sometimes allow the same mode to be re-set with the >> >> same bpp? >> > >> > So when userspace driver re-sets the same mode, the kernel will call the >> > mode valid function where it will see it can allow the sam mode perhaps >> > at a lower bpp now since the link parameters are lowered. >> > So the mode which failed at 30 bpp, might still work at 18bpp and is >> > better going to a lower resolution. >> >> The question was whether the kernel will ever allow the same mode at the >> same bpp, since that's what this patch tries to do. > > Yes, this can happen. Doing a full modeset with recomputing clocks and > everything behind userspace's back might not be something the kernel > driver can pull of with a reasonable amount of effort, hence why we punt > to userspace. The interface spec makes this a CAN, not WILL, to allow less > unreasonable hw to handle these cases directly in the kernel driver. E.g. > plain link-retraining is handled in i915.ko still. So in that case you do need userspace to re-request the same mode at the same bpp? 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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote: > Daniel Vetter writes: > > > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: > >> Manasi Navare writes: > >> > >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: > >> >> Manasi Navare writes: > >> >> > >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: > >> >> >> Martin Peres writes: > >> >> >> > >> >> >> > On 26/01/17 14:37, Martin Peres wrote: > >> >> >> >> Despite all the careful planing of the kernel, a link may become > >> >> >> >> insufficient to handle the currently-set mode. At this point, the > >> >> >> >> kernel should mark this particular configuration as being broken > >> >> >> >> and potentially prune the mode before setting the offending > >> >> >> >> connector's > >> >> >> >> link-status to BAD and send the userspace a hotplug event. This > >> >> >> >> may > >> >> >> >> happen right after a modeset or later on. > >> >> >> >> > >> >> >> >> When available, we should use the link-status information to reset > >> >> >> >> the wanted mode. > >> >> >> >> > >> >> >> >> Signed-off-by: Martin Peres > >> >> >> > > >> >> >> > The relevant kernel patches have landed in drm-tip about a month > >> >> >> > ago. > >> >> >> > > >> >> >> > Eric, would you mind providing feedback on or merging this patch? > >> >> >> > >> >> >> The later discussion has sounded like the kernel will (always) prune > >> >> >> the > >> >> >> mode when we re-query, meaning that it doesn't make any sense to try > >> >> >> to > >> >> >> re-set to the old mode. Is this not the case? > >> >> > > >> >> > > >> >> > No the kernel will simply send a hotplug with link status as bad > >> >> > and then after that point its userspace driver's responsibility > >> >> > to check if link status is BAD, retry the same mode and if it fails > >> >> > then re probe. > >> >> > >> >> So the kernel will sometimes allow the same mode to be re-set with the > >> >> same bpp? > >> > > >> > So when userspace driver re-sets the same mode, the kernel will call the > >> > mode valid function where it will see it can allow the sam mode perhaps > >> > at a lower bpp now since the link parameters are lowered. > >> > So the mode which failed at 30 bpp, might still work at 18bpp and is > >> > better going to a lower resolution. > >> > >> The question was whether the kernel will ever allow the same mode at the > >> same bpp, since that's what this patch tries to do. > > > > Yes, this can happen. Doing a full modeset with recomputing clocks and > > everything behind userspace's back might not be something the kernel > > driver can pull of with a reasonable amount of effort, hence why we punt > > to userspace. The interface spec makes this a CAN, not WILL, to allow less > > unreasonable hw to handle these cases directly in the kernel driver. E.g. > > plain link-retraining is handled in i915.ko still. > > So in that case you do need userspace to re-request the same mode at the > same bpp? So yes because when userspace requests the same mode at same bpp, kernel will still call intel_dp->mod_valid which validates the mode against 18bpp so if the requested mode can be displayed at the lowest of 18bpp, then the kernel will try to do the modeset for that mode at lower bpp. What I am trying to say is irrespective of what bpp userspace requests, kernel will check if it can display that at the lowest of 18bpp. Regards Manasi > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ 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
