Re: E-EDID support: read out extension blocks
On 8/14/12 9:47 AM, Christophe Oosterlynck wrote: Hi all, to be HDMI compliant, extension blocks provided by E-EDID should be read out. It seems that X doesn't do this. I've been browsing through the code and found a commit [1] which introduced the 'complete' parameter to xf86DoEEDID. This is being called with complete=FALSE from xf86DoEDID_DDC2 [2]. I was wondering why and if there is any other code path where this function is called with complete=TRUE? Or doesn't X support reading out extensions blocks by default and can it only be done by calling xf86DoEEDID myself? ... which the X drivers do, yes. What bit of HDMI compliance do you think we're missing here? All drivers that actually support the bits of HDMI beyond plain DVI have kernel support, and Linux does parse the HDMI extension block. - ajax ___ 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
special tablet keys X220t
Hi list! I've got a ThinkPad X220t, and already tried hard getting 3 buttons to work, showkey already provides keycodes: Tablet portrait: 153 Tablet rotation: 154 Microphone mute: 248 I've a long time, following various wiki pages like https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys_in_Xorg but had no luck. xev reports something when pressing the tablet buttons, but is completely quiet with the mic-key. This is what xev reports when pressing the 153-key: FocusOut event, serial 32, synthetic NO, window 0x301, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 32, synthetic NO, window 0x301, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 32, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Binding the keycode to just a or a special XF86 key doesn't help, no keypress event occurs to be captured by xev or my window manager (i3). These associations are displayed correctly with xmodmap -pk Anyone an idea how i can map those keycodes so they can trigger any bashscript? Cheers, Jonas signature.asc Description: OpenPGP digital signature ___ 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
E-EDID support: read out extension blocks
Hi all, to be HDMI compliant, extension blocks provided by E-EDID should be read out. It seems that X doesn't do this. I've been browsing through the code and found a commit [1] which introduced the 'complete' parameter to xf86DoEEDID. This is being called with complete=FALSE from xf86DoEDID_DDC2 [2]. I was wondering why and if there is any other code path where this function is called with complete=TRUE? Or doesn't X support reading out extensions blocks by default and can it only be done by calling xf86DoEEDID myself? [1] http://cgit.freedesktop.org/xorg/xserver/commit/?id=b4fbc31e109f1efe78613597f9a91d5363523493 [2] http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/ddc/ddc.c#n468 Best regards, Christophe ___ 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
答复: [PATCH]siliconmotion new driver initial patch
Hi Alan, Thank you for your reply. We will change the configure.ac/Makefile.am. But one more thing I need your advice. This is a initial patch. There are many code has been changed. In order to make the patch smaller shall I separate the patch into small parts? What kind of small parts shall I made? Aaron -邮件原件- 发件人: Alan Coopersmith [mailto:alan.coopersm...@oracle.com] 发送时间: 2012年8月13日 22:35 收件人: Aaron.Chen 陈俊杰 抄送: xorg-devel@lists.x.org 主题: Re: [PATCH]siliconmotion new driver initial patch On 08/12/12 11:07 PM, Aaron.Chen 陈俊杰 wrote: I didn't found this mail show up on the xorg-devel mail list and there is no response. Maybe it didn't sent successfully, so I sent it again. 2.2 MB mails require moderator approval to be sent to the mailing list. Please don't send multiple copies of multi-megabyte mails. Though really, you can also assume sending a single 2.2MB patch is a waste of time that no one will ever review, especially since the first few files shown continue to repeat mistakes we already told you we would not accept, such as undoing past cleanups of configure.ac/Makefile.am to revert them to older, less functional states. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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 3/3] Kludge -- Call RandR screen before cleaning up xf86 crtcs
On Wed, Aug 8, 2012 at 10:49 AM, Keith Packard kei...@keithp.com wrote:
The core RandR screen cleanup now involves cleaning up any GPU screen
associations, and those call down into DDX to clean up the driver. If
the pointers from the xf86 structures back to the core randr
structures are set to NULL at that point, bad things happen.
This patch knows that the core RandR close screen is underneath the
xf86 randr close screen function, and so makes sure it gets called
first.
Yeah its pretty kludgey but probably the best solution for now.
Reviewed-by: Dave Airlie airl...@redhat.com
Signed-off-by: Keith Packard kei...@keithp.com
---
hw/xfree86/modes/xf86Crtc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 154f684..1947c5be 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -726,6 +726,12 @@ xf86CrtcCloseScreen(ScreenPtr screen)
xf86RotateCloseScreen(screen);
+xf86RandR12CloseScreen(screen);
+
+free(config-name);
+
+screen-CloseScreen(screen);
+
for (o = 0; o config-num_output; o++) {
xf86OutputPtr output = config-output[o];
@@ -749,10 +755,7 @@ xf86CrtcCloseScreen(ScreenPtr screen)
else if (screen-current_master)
DetachUnboundGPU(screen);
}
-xf86RandR12CloseScreen(screen);
-
-free(config-name);
-return screen-CloseScreen(screen);
+return TRUE;
}
/*
--
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
___
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
Extension of Xorg server 32/64 Bits problem - SOLVED!
Hi, Just for Information: I had a strange problem with a small loadable extention for Xorg server but only on 64-Bit system. On 32-Bit Linux System the extention works fine, on 64-Bit system I got an error X Error of failed request: BadLength (poly request too large or internal Xlib length error). I have asked here in forum but nothing helps :( Now I know what the problem was and hope, this solution will help somebody who try to write a loadable extension too. Simply the /usr/include/xorg/xorg-server.h was missed! That is a generated header file and must be included at the first place in the extension AND NOT in the client application / lib! After including it the _XSERVER64 flag is set to 1 and everything allright!… HTH Leo ___ 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: Extension of Xorg server 32/64 Bits problem
Hi, Just for Information: I had a strange problem with a small loadable extention for Xorg server but only on 64-Bit system. On 32-Bit Linux System the extention works fine, on 64-Bit system I got an error X Error of failed request: BadLength (poly request too large or internal Xlib length error). I have asked here in forum but nothing helps Now I know what the problem was and hope, this solution will help somebody who try to write a loadable extension too. Simply the /usr/include/xorg/xorg-server.h was missed! That is a generated header file and must be included at the first place in the extension AND NOT in the client application / lib! After including it the _XSERVER64 flag is set to 1 and everything allright!… HTH Leo ___ 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] xauth: improve to handle FamilyWild necessary for GDM/XDMCP/SSH. #43425
Hello xorg-devel,
[ please CC me in your replies ]
This is an updated version of Tilmann Bubeck's patch for #43425 fixing
remarks by Walter Harms.
This patch is needed in case you use the following setup
Client-VNC-XDMCP (localhost)-GDM
In the above scenario you won't be able to forward your Display using
X11:
ssh -X $OTHERHOST xterm
Warning: No xauth data; using fake authentication data for X11
forwarding.
Invalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display
localhost:10.0
Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open
display: localhost:10.0
Original log message:
xauth is currently unable to handle FamilyWild. This gives problems
with GDM receiving XDMCP request which used FamilyWild. More details
in the referenced freedesktop bugzilla entry.
The patch improves xauth to handle that Family:
* allow dump_entry to deal with that Family and output
such entries correctly.
* allow list $DISPLAY to match against an entry in
XAUTHORITY of type FamilyWild.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43425
[ -- cut here -- ]
diff --git a/process.c b/process.c
index 283b4a1..49d1b13 100644
--- a/process.c
+++ b/process.c
@@ -462,7 +462,10 @@ read_auth_entries(FILE *fp, Bool numeric, AuthList
**headp, AuthList **tailp)
return n;
}
-static Bool
+/**
+ * Parse the given displayname and build a corresponding AuthList.
+ */
+static Bool
get_displayname_auth(const char *displayname, AuthList **authl)
{
int family;
@@ -991,6 +994,9 @@ dump_entry(const char *inputfilename, int lineno,
Xauth *auth, char *data)
fwrite (auth-address, sizeof (char), auth-address_length,
fp);
fprintf (fp, /unix);
break;
+ case FamilyWild:
+ fwrite (auth-address, sizeof (char), auth-address_length,
fp);
+ break;
case FamilyInternet:
#if defined(IPv6) defined(AF_INET6)
case FamilyInternet6:
@@ -1073,6 +1079,39 @@ match_auth_dpy(register Xauth *a, register Xauth
*b)
memcmp(a-number, b-number, a-number_length) == 0) ? 1 :
0);
}
+static int
+match_authwild_dpy(register Xauth *a, const char *displayname)
+{
+int family;
+char *host = NULL, *rest = NULL;
+int dpynum, scrnum;
+char dpynumbuf[40];/* want to hold largest
display num */
+
+if ( a-family != FamilyWild ) {
+ return False;
+}
+
+if (!parse_displayname (displayname,
+ family, host, dpynum, scrnum, rest)) {
+ if (host) free(host);
+ if (rest) free(rest);
+
+ return False;
+}
+
+dpynumbuf[0] = '\0';
+sprintf (dpynumbuf, %d, dpynum);
+
+if (a-address_length != strlen(host) || a-number_length !=
strlen(dpynumbuf))
+ return False;
+
+if (memcmp(a-address, host, a-address_length) == 0
+ memcmp(a-number, dpynumbuf, a-number_length) == 0)
+ return True;
+else
+ return False;
+}
+
/* return non-zero iff display and authorization type are the same */
static int
@@ -1236,13 +1275,22 @@ iterdpy (const char *inputfilename, int lineno,
int start,
/* l may be freed by remove_entry below. so save its
contents */
next = l-next;
tmp_auth = copyAuth(l-auth);
- for (proto = proto_head; proto; proto = proto-next) {
- if (match_auth_dpy (proto-auth, tmp_auth)) {
- matched = True;
- if (yfunc) {
- status = (*yfunc) (inputfilename, lineno,
- tmp_auth, data);
- if (status 0) break;
+
+ if ( match_authwild_dpy(tmp_auth, displayname) ) {
+ matched = True;
+ if (yfunc) {
+ status = (*yfunc) (inputfilename, lineno,
+ tmp_auth, data);
+ }
+ } else {
+ for (proto = proto_head; proto; proto = proto-next) {
+ if (match_auth_dpy (proto-auth, tmp_auth)) {
+ matched = True;
+ if (yfunc) {
+ status = (*yfunc) (inputfilename, lineno,
+ tmp_auth, data);
+ if (status 0) break;
+ }
}
}
}
___
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 v2 xorg-gtest] process: add state enum and GetState()
On 08/13/2012 06:20 PM, Peter Hutterer wrote:
Add a set of basic states to Process to allow callers to keep track of which
state a process is in (as seen from the library). This simplifies code that
needs to happen on certain conditions only, e.g. log file cleanup is only
needed if the process was previously started.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Changes to v1:
- Move enum to Process class to better confine it
- Check state on GetState(), update if it terminated on its own.
- Check state on KillSelf(), return true if it already terminated anyway
include/xorg/gtest/xorg-gtest-process.h | 17 +
src/process.cpp | 25 +
2 files changed, 42 insertions(+)
diff --git a/include/xorg/gtest/xorg-gtest-process.h
b/include/xorg/gtest/xorg-gtest-process.h
index 402be49..c4b2309 100644
--- a/include/xorg/gtest/xorg-gtest-process.h
+++ b/include/xorg/gtest/xorg-gtest-process.h
@@ -62,6 +62,16 @@ namespace testing {
*/
class Process {
public:
+ /**
+* Describes the state of a process.
+*/
+ enum State {
+ ERROR,/** An error has occured, state is now unknown */
+ NONE, /** The process has not been started yet */
+ RUNNING, /** The process has been started */
+ TERMINATED, /** The process was terminated by this library */
+ };
+
/**
* Helper function to adjust the environment of the current process.
*
@@ -179,6 +189,13 @@ class Process {
*/
pid_t Pid() const;
+ /**
+ * Return the state of the process.
+ *
+ * @return The current state of the process
+ */
+ enum Process::State GetState();
+
private:
struct Private;
std::auto_ptrPrivate d_;
diff --git a/src/process.cpp b/src/process.cpp
index 7df2b84..c976720 100644
--- a/src/process.cpp
+++ b/src/process.cpp
@@ -42,10 +42,26 @@
struct xorg::testing::Process::Private {
pid_t pid;
+ enum State state;
};
xorg::testing::Process::Process() : d_(new Private) {
d_-pid = -1;
+ d_-state = NONE;
+}
+
+enum xorg::testing::Process::State xorg::testing::Process::GetState() {
+ if (d_-state == RUNNING) {
+int status;
+int pid = waitpid(Pid(), status, WNOHANG);
+if (pid == Pid()) {
+ if (WIFEXITED(status))
+d_-pid = -1;
+d_-state = TERMINATED;
This will mark the process as having terminated cleanly, even if it
actually died due to an error. In fact, under the assumption that any
process is meant to be indefinitely long, any exit first noticed here is
an error.
Should we set state here to ERROR instead? In the successful path, we
will end up setting the state to TERMINATED inside KillSelf().
+}
+ }
+
+ return d_-state;
}
void xorg::testing::Process::Start(const std::string program, const
std::vectorstd::string argv) {
@@ -55,6 +71,7 @@ void xorg::testing::Process::Start(const std::string
program, const std::vector
d_-pid = fork();
if (d_-pid == -1) {
+d_-state = ERROR;
throw std::runtime_error(Failed to fork child process);
} else if (d_-pid == 0) { /* Child */
close(0);
@@ -73,8 +90,11 @@ void xorg::testing::Process::Start(const std::string
program, const std::vector
execvp(program.c_str(), args[0]);
+d_-state = ERROR;
throw std::runtime_error(Failed to start process);
}
+
+ d_-state = RUNNING;
}
void xorg::testing::Process::Start(const std::string program, va_list args) {
@@ -112,6 +132,9 @@ bool xorg::testing::Process::WaitForExit(unsigned int
timeout) {
bool xorg::testing::Process::KillSelf(int signal, unsigned int timeout) {
bool wait_success = true;
+ if (GetState() == TERMINATED)
+return true;
+
This would then be:
State state = GetState();
if (state == TERMINATED)
return true;
if (state == ERROR)
return false;
if (d_-pid == -1) {
return false;
} else if (d_-pid == 0) {
@@ -120,12 +143,14 @@ bool xorg::testing::Process::KillSelf(int signal,
unsigned int timeout) {
} else { /* Parent */
if (kill(d_-pid, signal) 0) {
d_-pid = -1;
+ d_-state = ERROR;
return false;
}
if (timeout 0)
wait_success = WaitForExit(timeout);
d_-pid = -1;
}
+ d_-state = TERMINATED;
return wait_success;
}
___
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 xorg-gtest 5/5] xserver: add RemoveLogFile()
On 08/13/2012 04:12 PM, Peter Hutterer wrote:
On Mon, Aug 13, 2012 at 09:32:00AM -0700, Chase Douglas wrote:
On 08/09/2012 10:38 PM, Peter Hutterer wrote:
Simple unlink() call to the logfile in use. The log file is only removed if
the server was started and terminated successfully. If it was never started
or the startup failed for some reason, this function does nothing.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/xorg/gtest/xorg-gtest-xserver.h | 6 ++
src/xserver.cpp | 5 +
2 files changed, 11 insertions(+)
diff --git a/include/xorg/gtest/xorg-gtest-xserver.h
b/include/xorg/gtest/xorg-gtest-xserver.h
index f3bda9b..33446a8 100644
--- a/include/xorg/gtest/xorg-gtest-xserver.h
+++ b/include/xorg/gtest/xorg-gtest-xserver.h
@@ -95,6 +95,12 @@ class XServer : public xorg::testing::Process {
virtual bool Kill(unsigned int timeout = 0);
/**
+ * Remove the log file used by this server. If the server was never
+ * started or the startup failed, this function does nothing.
+ */
+void RemoveLogFile();
+
+/**
* Waits until this server is ready to take connections.
*/
void WaitForConnections(void);
diff --git a/src/xserver.cpp b/src/xserver.cpp
index 86c8484..114c736 100644
--- a/src/xserver.cpp
+++ b/src/xserver.cpp
@@ -365,6 +365,11 @@ bool xorg::testing::XServer::Kill(unsigned int timeout) {
return true;
}
+void xorg::testing::XServer::RemoveLogFile() {
+ if (GetState() == TERMINATED)
+unlink(d_-options[-logfile].c_str());
+}
+
void xorg::testing::XServer::SetOption(const std::string key, const std::string
value) {
d_-options[key] = value;
}
I would prefer to call it something that gives a better idea that it
is conditional on successful termination of the server.
RemoveLogFile() sounds like a method that would *always* remove the
log file.
What about CleanUpLogFile()?
tbh, I don't think there's much difference between the two names, and, had
we both functions, I certainly couldn't tell the difference between the two
without reading the documentation. The behaviour is stated in the API
documentation and not removing what we didn't create is a good behaviour.
If it's not any clearer to you, then maybe there isn't a perfect
solution. I guess I'm ok with RemoveLogFile().
Or, you could just leave it up to the caller to call it only where
it should be called. The caller can get the state just the same.
Without the TERMINATED condition, this would simply be an unlink call, for
any file the caller wants. If callers really just wanted to remove a file
unconditionally, they can call unlink() themselves.
True.
After this discussion, I'm ready to give my tag:
Reviewed-by: Chase Douglas chase.doug...@canonical.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
Re: [PATCH xorg-gtest] process: document that va_args for Start() must end with zero-length string
On 08/13/2012 06:16 PM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/xorg/gtest/xorg-gtest-process.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/xorg/gtest/xorg-gtest-process.h
b/include/xorg/gtest/xorg-gtest-process.h
index 69b3b34..8cf60e3 100644
--- a/include/xorg/gtest/xorg-gtest-process.h
+++ b/include/xorg/gtest/xorg-gtest-process.h
@@ -123,7 +123,8 @@ class Process {
* See 'man execvp' for further information on the variadic argument list.
*
* @param program The program to start.
- * @param args Variadic list of arguments passed to the program.
+ * @param args Variadic list of arguments passed to the program. This list
+ * must end in a zero-length string (, not NULL).
*
* @throws std::runtime_error on failure.
*
@@ -135,7 +136,8 @@ class Process {
/**
* Starts a program as a child process.
*
- * Takes a variadic list of arguments passed to the program.
+ * Takes a variadic list of arguments passed to the program. This list
+ * must end in a zero-length string (, not NULL).
* See 'man execvp' for further information on the variadic argument list.
*
* @param program The program to start.
Hmmm... I wish we had though to use a NULL sentinel for the varargs
version. We could have used the gcc sentinel function attribute to help
warn people of bad usage. I suppose it's too late to change now that
we've released it.
Reviewed-by: Chase Douglas chase.doug...@canonical.com
And pushed as commit 4b8f4dd2b2be2bb036f75403ef4cef31d280f70b.
Thanks!
___
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] fb: reorder Bresenham error correction to avoid overshoot.
On Mon, Aug 13, 2012 at 1:57 PM, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: From: Simon Schubert 2...@0x2c.org When fbBresSolid draws a line, it can happen that after the last pixel, the Bresenham error term overflows, and fbBresSolid paints another pixel before adjusting the error term. However, if this happens on the last pixel (len=0), this extra pixel might overshoot the boundary, and, in rare cases, lead to a segfault. Fix this issue by adjusting for the Bresenham error term before drawing the main pixel, not after. This looks like something that should land for 1.13, right? -- keith.pack...@intel.com Yeah, I think so. ___ 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 modesetting] drmmode_display: add DRM_MODE_CONNECTOR_VIRTUAL to output_names
Added by a7331e5cb, since v3.2-rc1
Signed-off-by: Alon Levy al...@redhat.com
---
src/drmmode_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 5e38265..e455de9 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -882,7 +882,8 @@ const char *output_names[] = { None,
HDMI,
HDMI,
TV,
- eDP
+ eDP,
+ Virtual,
};
static void
--
1.7.11.2
___
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 xorg-gtest] process: document that va_args for Start() must end with zero-length string
On Tue, Aug 14, 2012 at 10:19:00AM -0700, Chase Douglas wrote:
On 08/13/2012 06:16 PM, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/xorg/gtest/xorg-gtest-process.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/xorg/gtest/xorg-gtest-process.h
b/include/xorg/gtest/xorg-gtest-process.h
index 69b3b34..8cf60e3 100644
--- a/include/xorg/gtest/xorg-gtest-process.h
+++ b/include/xorg/gtest/xorg-gtest-process.h
@@ -123,7 +123,8 @@ class Process {
* See 'man execvp' for further information on the variadic argument
list.
*
* @param program The program to start.
- * @param args Variadic list of arguments passed to the program.
+ * @param args Variadic list of arguments passed to the program. This list
+ * must end in a zero-length string (, not NULL).
*
* @throws std::runtime_error on failure.
*
@@ -135,7 +136,8 @@ class Process {
/**
* Starts a program as a child process.
*
- * Takes a variadic list of arguments passed to the program.
+ * Takes a variadic list of arguments passed to the program. This list
+ * must end in a zero-length string (, not NULL).
* See 'man execvp' for further information on the variadic argument
list.
*
* @param program The program to start.
Hmmm... I wish we had though to use a NULL sentinel for the varargs
version. We could have used the gcc sentinel function attribute to
help warn people of bad usage. I suppose it's too late to change now
that we've released it.
I disagree. We're only up to 0.4 and have few users only. Pretending we have
a good and stable API already is optimistic at best, it's better to fix the
things that are obviously (or at least reasonably :) broken. This isn't hard
thing to fix either (I'll send patches out in a bit), so there really isn't
an excuse for having a bad API, it'll just come and haunt us later.
Cheers,
Peter
___
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] fb: reorder Bresenham error correction to avoid overshoot.
Matt Turner matts...@gmail.com writes: From: Simon Schubert 2...@0x2c.org When fbBresSolid draws a line, it can happen that after the last pixel, the Bresenham error term overflows, and fbBresSolid paints another pixel before adjusting the error term. However, if this happens on the last pixel (len=0), this extra pixel might overshoot the boundary, and, in rare cases, lead to a segfault. Fix this issue by adjusting for the Bresenham error term before drawing the main pixel, not after. Merged. c22c936..863d528 master - master -- keith.pack...@intel.com pgpnf1FGyKqJu.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 3/3] Kludge -- Call RandR screen before cleaning up xf86 crtcs
Dave Airlie airl...@gmail.com writes: Yeah its pretty kludgey but probably the best solution for now. Reviewed-by: Dave Airlie airl...@redhat.com All three of these are merged. 863d528..c0540b4 master - master -- keith.pack...@intel.com pgp8tjCWWcySx.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] dix: work around scaling issues during WarpPointer (#53037)
Peter Hutterer peter.hutte...@who-t.net writes: In WarpPointer calls, we get input in screen coordinates. They must be scaled to device coordinates, and then back to screen coordinates for screen crossing and root coordinates in events. The rounding errors introduced (and clipping in core/XI 1.x events) can lead to the actual position being different to the requested input coordinates. e.g. 200 scales to 199., truncated to 199 in the event. Would it be useful to do a bit of rounding in these conversions somewhere? -- keith.pack...@intel.com pgpV47L13C3L3.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] dix: work around scaling issues during WarpPointer (#53037)
On Tue, Aug 14, 2012 at 05:19:45PM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: In WarpPointer calls, we get input in screen coordinates. They must be scaled to device coordinates, and then back to screen coordinates for screen crossing and root coordinates in events. The rounding errors introduced (and clipping in core/XI 1.x events) can lead to the actual position being different to the requested input coordinates. e.g. 200 scales to 199., truncated to 199 in the event. Would it be useful to do a bit of rounding in these conversions somewhere? The only place you can round is after scaling back into the screen coordinate system and there's still a small chance of failure. It largely depends on the difference between screen coordinate system and device coordinate system. So the two options we have are: 1) round() and take the potential errors. This is the better choice for devices where round() gives more than a pixel difference since device and root coordinates will have less of a difference. 2) force the explicit pointer position. This will hurt more for devices that are off by more than one pixel, but won't show up by those within a pixel. Feel free to calculate what the difference in coordinate systems must be to favour one of the other :) Cheers, Peter ___ 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
Driver autoload/autodetection for platform devices
Hey, I'm looking at the latest code included to support platform devices, and platform bus, and I'm trying to understand how it can be used to dynamically autoload/autodetect the drivers available at the system. At my current use case, I'm trying to get the xserver to automatically load the xf86-video-omap driver in case it's available at the system, and I'm running at a Pandaboard. Currently to make the driver to load, you need to create a xorg.conf just to point out to xserver which driver to load, and as I know platform devices support was improved by Dave, I want to understand what would be the steps needed to avoid having the xorg config file at the system just to use the omap xorg driver. Looking at the latest platform related code included by Dave, this is what is happening at my current system: 1 - xf86platformProbe is called, which register the udev callback for xf86PlatformDeviceProbe, which is also executed as we have a a valid dri/card0 available at the system (linux 3.4, using omap drm); 2 - The platform device for /dev/dri/card0 is registered by xf86_add_platform_device, setting the correct attributes but setting pdev as NULL; 3 - listPossibleVideoDrivers calls xf86PlatformMatchDriver, but as pdev is still null, it doesn't call xf86MatchDriverFromFiles; 4 - Xorg then loads fbdev and moves on; As we don't have a common bus to probe for devices, one way would be to also depend on xf86MatchDriverFromFiles, but for that we'd need to make sure we're probing the correct device/vendor id from the platform device. I don't know much about the details on how this could be done with drm/kms, so that's why I first wanted to know if that would be a really a valid path. Is there any other way where we could change at Xorg to be able to dynamically detect/load the platform (without a pci bus to probe) specific drivers? Thanks, -- Ricardo Salveti de Araujo ___ 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: Driver autoload/autodetection for platform devices
On Tue, Aug 14, 2012 at 10:45 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey, I'm looking at the latest code included to support platform devices, and platform bus, and I'm trying to understand how it can be used to dynamically autoload/autodetect the drivers available at the system. At my current use case, I'm trying to get the xserver to automatically load the xf86-video-omap driver in case it's available at the system, and I'm running at a Pandaboard. Currently to make the driver to load, you need to create a xorg.conf just to point out to xserver which driver to load, and as I know platform devices support was improved by Dave, I want to understand what would be the steps needed to avoid having the xorg config file at the system just to use the omap xorg driver. Looking at the latest platform related code included by Dave, this is what is happening at my current system: 1 - xf86platformProbe is called, which register the udev callback for xf86PlatformDeviceProbe, which is also executed as we have a a valid dri/card0 available at the system (linux 3.4, using omap drm); 2 - The platform device for /dev/dri/card0 is registered by xf86_add_platform_device, setting the correct attributes but setting pdev as NULL; 3 - listPossibleVideoDrivers calls xf86PlatformMatchDriver, but as pdev is still null, it doesn't call xf86MatchDriverFromFiles; 4 - Xorg then loads fbdev and moves on; As we don't have a common bus to probe for devices, one way would be to also depend on xf86MatchDriverFromFiles, but for that we'd need to make sure we're probing the correct device/vendor id from the platform device. I don't know much about the details on how this could be done with drm/kms, so that's why I first wanted to know if that would be a really a valid path. Is there any other way where we could change at Xorg to be able to dynamically detect/load the platform (without a pci bus to probe) specific drivers? Also, another issue I just noticed, is that even if we get the autoload/autodetect at the Xorg side, it'll still load fbdev even after omap is loaded (loading 2 different screens). Looking at the code, it seems that this happens because there's no way to control if the slot was claimed, because the omap driver uses xf86ClaimNoSlot instead of xf86ClaimPlatformSlot (not yet public, but would probably be the one to be called). So I believe another change that would be needed is to export xf86ClaimPlatformSlot as well, unless there's another way to control tell fbdev not to load it's own driver. Cheers, -- Ricardo Salveti de Araujo ___ 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:
On Fre, 2012-08-10 at 21:29 +0200, tryf zrthzrthz wrote: i ve a G4 and i cant install fedora 17 ppc i tried both dvd and cd (netinstall) ppc32 and it both did the same : it s started, it says i could have help if wanted but i pressed enter then it seems to work then some green ok things seemed to be loaded then black screen... ftp://fr2.rpmfind.net/linux/fedora-secondary/releases/17/Fedora/ppc/iso/ i downloaded it from here md5 where ok i m french thanks i have ATI radeon 9200 (aty, rv280) agp 32Mo vram If that's an iBook, sounds similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683796 . -- 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
Bug#683796: xserver-xorg-video-radeon: No 3D acceleration in iBook2 powerpc
On Don, 2012-08-09 at 05:11 -0700, Dan DeVoto wrote: --- On Wed, 8/8/12, Michel Dänzer daen...@debian.org wrote: I heard that this handover from OFfb to radeon KMS can cause problems in some cases. Maybe you can try adding video=offb:off to video=radeonfb:off . BTW, does the black screen occur only when X starts, or already when KMS takes over from OFfb, which according to the above happens about 10 seconds after the kernel starts booting? The black screen happens about 10 seconds after boot starts when the line appears onscreen: fb: conflicting fb...(it didn't give me time to read the rest, but I assume it's fb: conflicting fb hw usage radeondrmfb vs OFfb ATY,Fall_A - removing generic driver). Just to be clear about the symptoms, the screen is still lit, it's just colored black and there's nothing visible. Then when X starts in the boot process, the screen goes dark for a second as if it's powered off, then comes on again to a lit but black screen, then after another second switches to a slightly lower brightness level. When I switch to a console, something similar happens. Also, I can change the brightness of the black screen with the iBook's brightness keys. Okay, that sounds like there's no problem with the backlight, but for some reason the LCD is programmed to show only black. I added video=offb:off to video=radeonfb:off like you suggested but got the same result. Did you verify in dmesg that this resulted in OFfb being completely disabled? I.e. no messages from OFfb, in particular nothing about 'conflicting fb hw usage'? Maybe just provide the dmesg output from that again. -- 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
