Re: Why does fbdev_drv need a console?
Hello, Christoph Theis, le Sat 06 Apr 2013 16:03:19 +0200, a écrit : So my questions are: Why would we need a console at all? Well, at least to properly support console switching to get out/into the Xserver I guess. And if a console may be required can it then be made optional? Or is there any other way to open the console somewhere else? I tried to start the X server with vtXX arguments but with no success. Did you try the -sharevts option ? That's what is supposed to be used for the usage you mentioned: I have a Raspberry Pi and want to use 2 monitors, each of them with its own X server. Samuel ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
GSoC 2013, X Input
Hello, I am doing master degree of Cryptology and information security I have good C, Python, Scapy and some openGL skills, and i am interested to work on X Input : Add custom gesture recognition to touchpad and touchscreen driver module project this summer. I am looking for any comment about the difficulty and the content of the project, and also about my chances to be accepted if i apply for. Thanks in advance. Best Regards. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Extended Desktop (Span)
With Mac OS X 10.7.5. I used X11 with TSClientX to RDP to a Windows Terminal Services Server. The special thing about this setup was the fact that I use 3 monitors and the RDP session used them as one single desktop (5760 x 1200). I recently upgraded to OS X 10.8., only to find out that Apple replaced X11 with XQuartz. Now this spanned RDP session does not work anymore. I have been unable to get it working again. Any suggestion is greatly welcome. Thanks Axel Grau ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [PATCH] xf86: return NULL for xf86CompatOutput if
xserver/hw/modes: compat_output bad dereference.
The commit 37d956e3ac9513b74078882dff489f9b0a7a5a28 into
xserver/hw/modes/xf86Crtc.c xf86CrtcConfigInit() initializes
config-compat_output = -1;
So an unset compat_output is now invalid, a good property since the
previous initial compat_output == 0 is not guaranteed available. It
usually is available because a driver first calls xf86OutputCreate()
followed by xf86InitialConfiguration().
This change exposes a bug. During initial configuration a monitor
detection is attempted and if an EDID block is available the driver
calls xf86OutputSetEDID(). There a bad dereference occurs:
xf86InitialConfiguration(ScrnInfoPtr scrn, Bool canGrow)
- xf86ProbeOutputModes(scrn, width, height);
-- output_modes = (*output-funcs-get_modes) (output);
--- xf86OutputSetEDID(xf86OutputPtr output, xf86MonPtr edid_mon)
if (output == xf86CompatOutput(scrn))XX now bad dereference
- return config-output[config-compat_output];
xf86SetDDCproperties(scrn, edid_mon);XX for screen monitor
- xf86SetScrnInfoModes(scrn);
-- output = SetCompatOutput(config); XX sets compat_output
--- config-compat_output = compat;
Hence previously the screen monitor properties were always copied from
output 0 since compat_output is only set at the end of the function.
The suggestion
If there is no compat output, config-compat_output is -1 and
xf86CompatOutput
reads before the beginning of the outputs array.
Signed-off-by: Aaron Plattner aplatt...@nvidia.com
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 802303f..1ac8485 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -731,6 +731,8 @@ xf86CompatOutput(ScrnInfoPtr pScrn)
{
xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn);
+if (config-compat_output 0)
+return NULL;
return config-output[config-compat_output];
}
Tested-by: Servaas Vandenberghe avoids the bad dereference.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xserver/hw/modes compat_output xf86SetDDCproperties()
The commit 37d956e3ac9513b74078882dff489f9b0a7a5a28 into
xserver/hw/modes/xf86Crtc.c xf86CrtcConfigInit() modified the
initialization of config-compat_output from default 0 to -1.
This change exposes a bug. During initial configuration a monitor
detection is attempted and if an EDID block is available the driver
calls xf86OutputSetEDID(). There the output in process is checked for
equality to the compat_output, and if equal then EDID is additionally
copied into the screen monitor properties, through
xf86SetDDCproperties() and xf86EdidMonitorSet(). Tracing:
xf86InitialConfiguration(ScrnInfoPtr scrn, Bool canGrow)
- xf86ProbeOutputModes(scrn, width, height);
-- output_modes = (*output-funcs-get_modes) (output);
--- xf86OutputSetEDID(xf86OutputPtr output, xf86MonPtr edid_mon)
if (output == xf86CompatOutput(scrn))XX now bad dereference
- return config-output[config-compat_output];
xf86SetDDCproperties(scrn, edid_mon);XX for screen monitor
- xf86SetScrnInfoModes(scrn);
-- output = SetCompatOutput(config); XX sets compat_output
--- config-compat_output = compat;
Hence during initial boot xf86SetDDCproperties() used to be called for
output 0 but is now never called since there is no output -1.
To reproduce:
1. in the Section Device add the Option ModeDebug on,
2. connect a single EDID monitor,
3. ~# X :1 -retro
4. un- and replug the monitor.
Xorg.1.log:
[347954.434] (II) RADEON(0): Output VGA-0 has no monitor section
[347954.434] (II) RADEON(0): xf86InitialConfiguration config-compat_output=-1
[347954.434] (**) RADEON(0): Option ModeDebug on
[347954.466] (II) RADEON(0): EDID for output DVI-0
...
[347954.467] (II) RADEON(0):00363230303036313959420a2020003f
[347954.467] (II) RADEON(0): Not using mode 720x576@25i (hsync out of range)
...
XX disconnect
[347977.171] (II) RADEON(0): EDID for output DVI-0
[347977.173] (II) RADEON(0): EDID for output HDMI-0
...
XX reconnect
[347992.820] (II) RADEON(0): EDID for output DVI-0
...
[347992.821] (II) RADEON(0):00363230303036313959420a2020003f
XX xf86SetDDCproperties() - xf86EdidMonitorSet() - xf86DDCGetModes()
[347992.821] (II) RADEON(0): EDID vendor NEC, prod id 26288
[347992.821] (II) RADEON(0): Using hsync ranges from config file
[347992.821] (II) RADEON(0): Using vrefresh ranges from config file
[347992.821] (II) RADEON(0): Printing DDC gathered Modelines:
...
[347992.821] (II) RADEON(0): Not using mode 720x576@25i (hsync out of range)
...
So consistency between scrn-monitor and scrn-modes requires a call
sequence xf86SetDDCproperties() followed by xf86SetScrnInfoModes().
Two places seem fit: at the begin of xf86SetScrnInfoModes() or at the
end of SetCompatOutput().
This patch takes the latter route. It combines the if-then-else tree
for readability, but execution is unchanged since
1. output == NULL == compat = -1
2. num_output 0 == config-output[0 .. (num_output-1)] != NULL
Also, the compat_output preset in xf86TargetFallback() is removed
since its selection differs from the SetCompatOutput() logic.
Signed-off-by: Servaas Vandenberghe
---
hw/xfree86/modes/xf86Crtc.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index f9ae465..1d15a46 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1832,17 +1832,21 @@ SetCompatOutput(xf86CrtcConfigPtr config)
}
if (compat = 0) {
-config-compat_output = compat;
+if (compat != config-compat_output) {
+config-compat_output = compat;
+/* Set screen scrn-monitor info. */
+xf86SetDDCproperties(output-scrn, output-MonInfo);
+}
}
else if (config-compat_output = 0 config-compat_output
config-num_output) {
/* Don't change the compat output when no valid outputs found */
output = config-output[config-compat_output];
}
-
-/* All outputs are disconnected, select one to fake */
-if (!output config-num_output) {
+else if (config-num_output 0) {
+/* All outputs are disconnected, select one to fake */
config-compat_output = 0;
output = config-output[config-compat_output];
+xf86SetDDCproperties(output-scrn, output-MonInfo);
}
return output;
@@ -2174,7 +2178,7 @@ xf86TargetFallback(ScrnInfoPtr scrn, xf86CrtcConfigPtr
config,
DisplayModePtr target_mode = NULL;
Rotation target_rotation = RR_Rotate_0;
DisplayModePtr default_mode;
-int default_preferred, target_preferred = 0, o;
+int default_preferred, target_preferred = 0, target_output, o;
/* User preferred preferred other modes */
for (o = -1; nextEnabledOutput(config, enabled, o);) {
@@ -2189,12 +2193,12 @@ xf86TargetFallback(ScrnInfoPtr scrn, xf86CrtcConfigPtr
config,
target_mode = default_mode;
target_preferred = default_preferred;
gsoc 2013 idea - Customizable gestures
Hello, My name is Samprit Biswas and I am a sophomore student at the Indian Institute of Technology Kharagpur, India of the department of Computer Science and Engineering. I would like to join the X.org project as a student on the Google Summer of Code program 2013. I am particularly interested in X input which allows a user to customize gestures. I have good knowledge in C/C++. I would like to know more about X Window Systems and some links would be helpful. I would also like to know whether any prerequisites are needed such as submitting some code/patches etc. Regards, Samprit Biswas E-mail : sampritbis...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
GSoC Call for Projects and Mentors
As some of you may know, the X.Org Foundation was accepted as a GSoC Project for 2013. If you would be interested in participating as either a mentor or a student, please sign up here: http://www.google-melange.com/gsoc/homepage/google/gsoc2013 For students, you can see some potential projects ideas here to get you started: http://www.x.org/wiki/SummerOfCodeIdeas If anyone has any questions, let me know. Thanks! Alex ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Xi: Use correct destination when swapping barrier events
Whoops. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Tue, Apr 9, 2013 at 7:23 PM, Keith Packard kei...@keithp.com wrote: Write the swapped values to the destination rather than the source. Signed-off-by: Keith Packard kei...@keithp.com --- Xi/extinit.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/Xi/extinit.c b/Xi/extinit.c index 619d0e4..02fffe5 100644 --- a/Xi/extinit.c +++ b/Xi/extinit.c @@ -848,24 +848,24 @@ SBarrierEvent(xXIBarrierEvent * from, *to = *from; -swaps(from-sequenceNumber); -swapl(from-length); -swaps(from-evtype); -swapl(from-time); -swaps(from-deviceid); -swaps(from-sourceid); -swapl(from-event); -swapl(from-root); -swapl(from-root_x); -swapl(from-root_y); - -swapl(from-dx.integral); -swapl(from-dx.frac); -swapl(from-dy.integral); -swapl(from-dy.frac); -swapl(from-dtime); -swapl(from-barrier); -swapl(from-eventid); +swaps(to-sequenceNumber); +swapl(to-length); +swaps(to-evtype); +swapl(to-time); +swaps(to-deviceid); +swaps(to-sourceid); +swapl(to-event); +swapl(to-root); +swapl(to-root_x); +swapl(to-root_y); + +swapl(to-dx.integral); +swapl(to-dx.frac); +swapl(to-dy.integral); +swapl(to-dy.frac); +swapl(to-dtime); +swapl(to-barrier); +swapl(to-eventid); } /** Event swapping function for XI2 events. */ -- 1.7.10.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Jasper ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/6] xfree86: Handle drm race condition
Bryce Harrington br...@canonical.com writes: So, feel free to revert the patches if the thinking is it's just adding clutter, but you may still want the first patch in the series as it adds a missing close(). We also found that having the server print out the error code helped in diagnosing the problem. Thanks! The diagnostic messages are probably useful, but let's revert the actual work-arounds so we're not stuck with mysterious code in the server. I'd appreciate it greatly if you would post a patch pulling the work-arounds out; I'll review and integrate it. -- keith.pack...@intel.com pgpXthLh1OQdn.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] radeonsi: add 2d tiling support
On Mon, 2013-04-08 at 13:46 -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Signed-off-by: Jerome Glisse jgli...@redhat.com Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
