Re: [Q] Xorg VNC driver?
On Tue, Sep 29, 2009 at 6:23 PM, Peter Hutterer wrote: > To get the wheel support, just inc NBUTTONS to 7 and set it up with the Thanks for the info, attached is a new version of hw/vnc/init.c that has mouse wheel support (copied from hw/xquartz/darwin.c). Oh, and this version actually compiles with the current git tree. BTW, my built Xvnc does not yet work correctly, I am currently trying to debug this problem (the "=+=" msg is my debug printf) : Starting program: /pek/Git/Xorg_test/xserver/hw/vnc/Xvnc :2 [Thread debugging using libthread_db enabled] [New Thread 0xb7b446c0 (LWP 16365)] 29/09/2009 19:16:08 Xvnc version X.org/xf4vnc custom version 29/09/2009 19:16:08 Copyright (C) 2001-2004 Alan Hourihane. 29/09/2009 19:16:08 Copyright (C) 2000-2004 Constantin Kaplinsky 29/09/2009 19:16:08 Copyright (C) 1999 AT&T Laboratories Cambridge 29/09/2009 19:16:08 All Rights Reserved. 29/09/2009 19:16:08 See http://www.tightvnc.com/ for information on TightVNC 29/09/2009 19:16:08 See http://xf4vnc.sf.net for xf4vnc-specific information 29/09/2009 19:16:08 Desktop name 'x11' (vost:2) 29/09/2009 19:16:08 Protocol versions supported: 3.7, 3.3 29/09/2009 19:16:09 Listening for VNC connections on TCP port 5902 =+= ActivateDevice: dev: 0x98b9df0 se: 1 deviceProc: 0x8152980 IM:1 sO: 0x1 DCI: 0x80a6c10 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b446c0 (LWP 16365)] 0x in ?? () (gdb) where #0 0x in ?? () #1 0x0815359b in ActivateDevice (dev=0x98b9df0, sendevent=) at devices.c:501 #2 0x08154538 in InitCoreDevices () at devices.c:634 #3 0x0813982e in main (argc=2, argv=0xbfa429e4, envp=0xb7cc3170) at main.c:256 Pat On Tue, Sep 29, 2009 at 6:23 PM, Peter Hutterer wrote: > On Tue, Sep 29, 2009 at 05:59:34PM +0200, Matthias Hopf wrote: >> On Sep 23, 09 14:33:24 -0500, Pat Kane wrote: >> > On Wed, Sep 23, 2009 at 8:46 AM, Matthias Hopf wrote: >> > > Sorry, porting was only to 1.6.3.901 (just noted that). However, they >> > > will probably a good start. >> > They provide a very good staring point and have saved me a lot of >> > work, thank you. >> > >> > I think the the mouse init code, init.c, needs to look somthing like >> > the attached snippet >> > of code (sorry I can not make patches yet). Does that look right? >> >> It doesn't look wrong (though I'm unsure how z axis i.e. mouse wheel is >> handled, and in the code I can only see handling of 3 buttons and 2 >> axes), but I'm not exactly fluent in that area. > > if the driver posts wheels as buttons 4/5 the server will ignore them if it > isn't set up. So the previous snippet is correct though without mouse > wheel support. > > To get the wheel support, just inc NBUTTONS to 7 and set it up with the > labels BTN_LABEL_PROP_BTN_WHEEL_UP, BTN_LABEL_PROP_BTN_WHEEL_DOWN, > BTN_LABEL_PROP_BTN_HWHEEL_LEFT, BTN_LABEL_PROP_BTN_HWHEEL_RIGHT. > > Note that button labelling is still optional, a label of 0 is permitted. > Labels are a hint to clients so they know what a given button does. For any > button from 1-7 labels are arguably superfluous since we can't change much > anyway - too many clients rely on the current behaviour. > > Cheers, > Peter > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > /* * init.c * * Modified for XFree86 4.x by Alan Hourihane * Modified for Xorg 1.7by Pat Kane */ /* * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved. * * This is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This software is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this software; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, * USA. */ /* Copyright (c) 1993 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMI
Re: [Q] Xorg VNC driver?
On Tue, Sep 29, 2009 at 05:59:34PM +0200, Matthias Hopf wrote: > On Sep 23, 09 14:33:24 -0500, Pat Kane wrote: > > On Wed, Sep 23, 2009 at 8:46 AM, Matthias Hopf wrote: > > > Sorry, porting was only to 1.6.3.901 (just noted that). However, they > > > will probably a good start. > > They provide a very good staring point and have saved me a lot of > > work, thank you. > > > > I think the the mouse init code, init.c, needs to look somthing like > > the attached snippet > > of code (sorry I can not make patches yet). Does that look right? > > It doesn't look wrong (though I'm unsure how z axis i.e. mouse wheel is > handled, and in the code I can only see handling of 3 buttons and 2 > axes), but I'm not exactly fluent in that area. if the driver posts wheels as buttons 4/5 the server will ignore them if it isn't set up. So the previous snippet is correct though without mouse wheel support. To get the wheel support, just inc NBUTTONS to 7 and set it up with the labels BTN_LABEL_PROP_BTN_WHEEL_UP, BTN_LABEL_PROP_BTN_WHEEL_DOWN, BTN_LABEL_PROP_BTN_HWHEEL_LEFT, BTN_LABEL_PROP_BTN_HWHEEL_RIGHT. Note that button labelling is still optional, a label of 0 is permitted. Labels are a hint to clients so they know what a given button does. For any button from 1-7 labels are arguably superfluous since we can't change much anyway - too many clients rely on the current behaviour. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Q] Xorg VNC driver?
On Wed, Sep 23, 2009 at 02:33:24PM -0500, Pat Kane wrote:
> On Wed, Sep 23, 2009 at 8:46 AM, Matthias Hopf wrote:
> >
> > On Sep 23, 09 08:09:58 -0500, Pat Kane wrote:
> > > Has anyone ported xf4vnc to xorg-server 1.7 (1.6.99)?
> > Sorry, porting was only to 1.6.3.901 (just noted that). However, they
> > will probably a good start.
>
> They provide a very good staring point and have saved me a lot of
> work, thank you.
>
> I think the the mouse init code, init.c, needs to look somthing like
> the attached snippet
> of code (sorry I can not make patches yet). Does that look right?
>
> I am lookig forward to having the code in a git repo.
>
> Pat
> ---
> ...
>
> static int
> rfbMouseProc(pDevice, onoff)
> DeviceIntPtr pDevice;
> int onoff;
> {
> #define NBUTTONS 3
> #define NAXES 2
> BYTE map[NBUTTONS + 1];
> Atom btn_labels[NBUTTONS] = {0};
> Atom axes_labels[NAXES] = {0};
> DevicePtr pDev = (DevicePtr)pDevice;
>
> switch (onoff)
> {
> case DEVICE_INIT:
> PtrDeviceInit();
> map[1] = 1;
> map[2] = 2;
> map[3] = 3;
>
> btn_labels[0] = XIGetKnownProperty(BTN_LABEL_PROP_BTN_LEFT);
> btn_labels[1] = XIGetKnownProperty(BTN_LABEL_PROP_BTN_MIDDLE);
> btn_labels[2] = XIGetKnownProperty(BTN_LABEL_PROP_BTN_RIGHT);
>
> axes_labels[0] = XIGetKnownProperty(AXIS_LABEL_PROP_REL_X);
> axes_labels[1] = XIGetKnownProperty(AXIS_LABEL_PROP_REL_Y);
>
>
> if (! InitPointerDeviceStruct(pDev, map,
> NBUTTONS, btn_labels,
> (PtrCtrlProcPtr)NoopDDA,
> GetMotionHistorySize(),
> NAXES, axes_labels))
> {
> ErrorF("Could not initialize device '%s'. Out of memory.\n",
>pDev->name);
> return BadAlloc; /* IPDS only fails on allocs */
> }
> pDev->valuator->axisVal[0] = screenInfo.screens[0]->width / 2;
> pDev->last.valuators[0]= pDev->valuator->axisVal[0];
> pDev->valuator->axisVal[1] = screenInfo.screens[0]->height / 2;
> pDev->last.valuators[1]= pDev->valuator->axisVal[1];
>
> vncSetPointerDevice(pDevice);
> break;
>
> case DEVICE_ON:
>
> ...
yep, this is the standard snippet for devices that are fixed (LMR buttons
and 2 rel axes).
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.6.4 brown-bag DGA fixes
Excerpts from Daniel Stone's message of Tue Sep 29 12:34:55 -0700 2009: > Well, if the objective is to never have the driver call the real > DGA initialisation, but to have DGAInit() present for API/linker > reasons, then, er ... heh. 1.6 is supposed to not break stuff, so we'll avoid that for now. I suggest that the patch be applied as-is to 1.7 and we consider whacking DGA around for 1.8. I want to cherry-pick this back and push a 1.6.5 out asap; 1.6.4 needs to get replaced. -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xkeyboard-config 1.7
Another stable release of xkeyboard-config is out - now the number is 1.7 The only substantial change is introduction of "exotic" configuration materials, exposed in separate directory files (*.extras.xml). This feature is supported by the latest libxklavier and GNOME. Some bugs are fixed (~30), new configuration components added. Updated translations are included, thanks to TP. The files are on the freedesktop site: http://xlibs.freedesktop.org/xkbdesc/xkeyboard-config-1.7.tar.bz2 http://xlibs.freedesktop.org/xkbdesc/xkeyboard-config-1.7.tar.gz The tag in git is v_1_7 Bug reports are very welcome: https://bugs.freedesktop.org/enter_bug.cgi?product=xkeyboard-config Cheers, Sergey ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.6.4 brown-bag DGA fixes
On Tue, Sep 29, 2009 at 11:41:42AM -0700, Keith Packard wrote: > Excerpts from Daniel Stone's message of Tue Sep 29 11:23:33 -0700 2009: > > You don't want to just no-op DGAInit? > > And have the DiDGA layer call some other 'real' DGAInit function? Well, if the objective is to never have the driver call the real DGA initialisation, but to have DGAInit() present for API/linker reasons, then, er ... Cheers, Daniel pgpvjGhqCTC3d.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.6.4 brown-bag DGA fixes
Excerpts from Daniel Stone's message of Tue Sep 29 11:23:33 -0700 2009: > You don't want to just no-op DGAInit? And have the DiDGA layer call some other 'real' DGAInit function? -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.6.4 brown-bag DGA fixes
On Tue, Sep 29, 2009 at 10:59:24AM -0700, Keith Packard wrote: > The fix I proposed doesn't solve the case where DGA is initialized > twice, once by the driver and once by the DiDGA layer. Here's a > version which has the DiDGA code override the driver DGA > initialization. You don't want to just no-op DGAInit? Cheers, Daniel pgp3St0bQHP6l.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
sensing X connection failure/timeout
I'm displaying clients on a remote X server and if I power the X
server box or pull the network cable some of the clients never
terminate. Some clients (fbpanel and gnome-screensaver in particular)
terminate and write "Fatal IO error 110 (Connection timeout) on X
server " to stderr, openbox the window manager we are
using does not ever realize that the server is gone. Looking at the
openbox main loop code:
void ob_main_loop_run(ObMainLoop *loop)
{
XEvent e;
struct timeval *wait;
fd_set selset;
GSList *it;
int rc;
loop->run = TRUE;
loop->running = TRUE;
while (loop->run) {
if (loop->signal_fired) {
guint i;
sigset_t oldset;
/* block signals so that we can do this without the data changing
on us */
sigprocmask(SIG_SETMASK, &all_signals_set, &oldset);
for (i = 0; i < NUM_SIGNALS; ++i) {
while (loop->signals_fired[i]) {
for (it = loop->signal_handlers[i];
it; it = g_slist_next(it)) {
ObMainLoopSignalHandlerType *h = it->data;
h->func(i, h->data);
}
loop->signals_fired[i]--;
}
}
loop->signal_fired = FALSE;
sigprocmask(SIG_SETMASK, &oldset, NULL);
} else if (XPending(loop->display)) {
do {
XNextEvent(loop->display, &e);
for (it = loop->x_handlers; it; it = g_slist_next(it)) {
ObMainLoopXHandlerType *h = it->data;
h->func(&e, h->data);
}
} while (XPending(loop->display) && loop->run);
} else {
/* this only runs if there were no x events received */
timer_dispatch(loop, (GTimeVal**)&wait);
selset = loop->fd_set;
/* there is a small race condition here. if a signal occurs
between this if() and the select() then we will not process
the signal until 'wait' expires. possible solutions include
using GStaticMutex, and having the signal handler set 'wait'
to 0 */
if (!loop->signal_fired)
rc = select(loop->fd_max + 1, &selset, NULL, NULL, wait);
/* handle the X events with highest prioirity */
if (FD_ISSET(loop->fd_x, &selset))
continue;
g_hash_table_foreach(loop->fd_handlers,
fd_handle_foreach, &selset);
}
}
loop->running = FALSE;
}
I see that if there are no X event it does a select on an fd set
initialized as follows:
loop->fd_x = ConnectionNumber(display);
FD_ZERO(&loop->fd_set);
FD_SET(loop->fd_x, &loop->fd_set);
loop->fd_max = loop->fd_x;
with a wait of NULL (infinite) and it never returns.
What is the proper way to determine that a remote server connection
has failed or timed out?
Ted
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 1.6.4 brown-bag DGA fixes
The fix I proposed doesn't solve the case where DGA is initialized
twice, once by the driver and once by the DiDGA layer. Here's a
version which has the DiDGA code override the driver DGA
initialization.
>From e1040dff8b783150a091dcf35c4ade21be40a5df Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Mon, 28 Sep 2009 12:39:47 -0700
Subject: [PATCH] Re-fix DGA removal.
Removing DGA ended up breaking any drivers calling into the old
xf86DiDGAInit function as it tried to see if DGA was already enabled
and ended up crashing if the VT wasn't completely initialized. Oops.
Also, if the driver initializes DGA itself, have the DiDGA
initialization overwrite that information as the DiDGA code will call
ReInit on mode detect.
Signed-off-by: Keith Packard
---
hw/xfree86/common/xf86DGA.c | 29 -
hw/xfree86/modes/xf86Crtc.c |4 ++--
hw/xfree86/modes/xf86Crtc.h |8
hw/xfree86/modes/xf86DiDGA.c | 15 ---
4 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/hw/xfree86/common/xf86DGA.c b/hw/xfree86/common/xf86DGA.c
index a06f285..3f7deba 100644
--- a/hw/xfree86/common/xf86DGA.c
+++ b/hw/xfree86/common/xf86DGA.c
@@ -120,8 +120,22 @@ DGAInit(
DGAScreenKey = &DGAScreenKeyIndex;
-if(!(pScreenPriv = (DGAScreenPtr)xalloc(sizeof(DGAScreenRec
- return FALSE;
+pScreenPriv = DGA_GET_SCREEN_PRIV(pScreen);
+
+if (!pScreenPriv)
+{
+ if(!(pScreenPriv = (DGAScreenPtr)xalloc(sizeof(DGAScreenRec
+ return FALSE;
+ dixSetPrivate(&pScreen->devPrivates, DGAScreenKey, pScreenPriv);
+ pScreenPriv->CloseScreen = pScreen->CloseScreen;
+ pScreen->CloseScreen = DGACloseScreen;
+ pScreenPriv->DestroyColormap = pScreen->DestroyColormap;
+ pScreen->DestroyColormap = DGADestroyColormap;
+ pScreenPriv->InstallColormap = pScreen->InstallColormap;
+ pScreen->InstallColormap = DGAInstallColormap;
+ pScreenPriv->UninstallColormap = pScreen->UninstallColormap;
+ pScreen->UninstallColormap = DGAUninstallColormap;
+}
pScreenPriv->pScrn = pScrn;
pScreenPriv->numModes = num;
@@ -146,17 +160,6 @@ DGAInit(
modes[i].flags &= ~DGA_PIXMAP_AVAILABLE;
#endif
-dixSetPrivate(&pScreen->devPrivates, DGAScreenKey, pScreenPriv);
-pScreenPriv->CloseScreen = pScreen->CloseScreen;
-pScreen->CloseScreen = DGACloseScreen;
-pScreenPriv->DestroyColormap = pScreen->DestroyColormap;
-pScreen->DestroyColormap = DGADestroyColormap;
-pScreenPriv->InstallColormap = pScreen->InstallColormap;
-pScreen->InstallColormap = DGAInstallColormap;
-pScreenPriv->UninstallColormap = pScreen->UninstallColormap;
-pScreen->UninstallColormap = DGAUninstallColormap;
-
-
return TRUE;
}
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 899cea5..4f31511 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -770,7 +770,7 @@ xf86CrtcScreenInit (ScreenPtr screen)
screen->CloseScreen = xf86CrtcCloseScreen;
#ifdef XFreeXDGA
-xf86DiDGAInit(screen, 0);
+_xf86_di_dga_init_for_reals(screen);
#endif
#ifdef RANDR_13_INTERFACE
return RANDR_INTERFACE_VERSION;
@@ -1887,7 +1887,7 @@ xf86SetScrnInfoModes (ScrnInfoPtr scrn)
scrn->currentMode = scrn->modes;
#ifdef XFreeXDGA
if (scrn->pScreen)
- xf86DiDGAReInit(scrn->pScreen);
+ _xf86_di_dga_reinit_for_reals(scrn->pScreen);
#endif
}
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 0a596bc..0f79066 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -807,6 +807,10 @@ xf86OutputGetEDID (xf86OutputPtr output, I2CBusPtr
pDDCBus);
Bool
xf86DiDGAInit (ScreenPtr pScreen, unsigned long dga_address);
+/* this is the real function, used only internally */
+_X_INTERNAL Bool
+_xf86_di_dga_init_for_reals (ScreenPtr pScreen);
+
/**
* Re-initialize dga for this screen (as when the set of modes changes)
*/
@@ -814,6 +818,10 @@ xf86DiDGAInit (ScreenPtr pScreen, unsigned long
dga_address);
Bool
xf86DiDGAReInit (ScreenPtr pScreen);
+/* This is the real function, used only internally */
+_X_INTERNAL Bool
+_xf86_di_dga_reinit_for_reals (ScreenPtr pScreen);
+
/*
* Set the subpixel order reported for the screen using
* the information from the outputs
diff --git a/hw/xfree86/modes/xf86DiDGA.c b/hw/xfree86/modes/xf86DiDGA.c
index 3992c09..f93810d 100644
--- a/hw/xfree86/modes/xf86DiDGA.c
+++ b/hw/xfree86/modes/xf86DiDGA.c
@@ -175,6 +175,12 @@ static DGAFunctionRec xf86_dga_funcs = {
_X_EXPORT Bool
xf86DiDGAReInit (ScreenPtr pScreen)
{
+return TRUE;
+}
+
+_X_INTERNAL Bool
+_xf86_di_dga_reinit_for_reals (ScreenPtr pScreen)
+{
ScrnInfoPtrscrn = xf86Screens[pScreen->myNum];
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
@@ -190,12 +196,15 @@ xf86DiDGAReInit (ScreenPtr pScreen)
_X_EXPORT Bool
xf86DiDGAInit
Re: [ANNOUNCE] xorg-server 1.6.4
Hi
I have tried 1.6.4 + my distro's patches and it segfaults at the DGA stuff.
Then I added keith's patch and it still segfaults (but now it doesn't
print on the log and seems to freeze the machine. the only way to
detect the segfault is to ssh the machine and then run X).
Pasting IRC log since I'm lazy:
jcristau: MrCooper: the package i'm using is not exactly the
upstream package (it's 1.6.4 + keithp's patch + the distro's patches)
and here is the backtrace: http://pastebin.com/m33f8b2ca
and it keeps printing forever that same line on the backtrace
* jeremyhu saiu ("Leaving")
looks very much like stack overflow
looks like the function is calling itself
or some other fun stack corruption.
yeah, infinite recursion
pzanoni: please follow up to keithp's patch post with this
information
sure looks like DGA is getting mis-connected
DGAInit called twice?
yeah
dunno how that could happen though
pzanoni: put a breakpoint on DGAInit, see where it's called from?
yeah, if the driver calls DGAInit, bad things will happen
Breakpoint 1, DGAInit (pScreen=0x9396310, funcs=0x937b26c,
modes=0x939c810,
num=63) at xf86DGA.c:110
110 ){
(gdb) bt
#0 DGAInit (pScreen=0x9396310, funcs=0x937b26c,
modes=0x939c810, num=63)
at xf86DGA.c:110
#1 0xb79f333b in RADEONDGAInit ()
from /usr/lib/xorg/modules/drivers//radeon_drv.so
#2 0xb79fed10 in RADEONScreenInit ()
from /usr/lib/xorg/modules/drivers//radeon_drv.so
#3 0x0806cae9 in AddScreen (pfnInit=0xb79fd210
, argc=1,
argv=0xbffaad64) at main.c:703
#4 0x080ad133 in InitOutput (pScreenInfo=0x821f1e0, argc=1,
argv=0xbffaad64)
at xf86Init.c:1256
#5 0x0806d1d0 in main (argc=1, argv=0xbffaad64,
envp=0xbffaad6c) at main.c:316
oops
the radeon driver releases certainly do call it
MrCooper: does radeon support framebuffer resize?
only with KMS, which isn't released yet
ok.
framebuffer resize means DGA will crash your machine
the current Git code no longer calls any *DGAInit
MrCooper: very sensible
ati 6.12.4, /proc/config.gz tells me CONFIG_DRM_RADEON_KMS is not set
MrCooper: should be easy to work around; just make DGAInit
check for an existing private
cool
Frankly, I think I'll make the xf86DiDGA override the radeon DGA code
as the DiDGA code will always re-initialize it on mode switch
* efw saiu (Read error: 110 (Connection timed out))
do I still need to send the email? =P
* rnoland saiu (Remote closed the connection)
pzanoni: please, I'll reply with an amended patch
On Mon, Sep 28, 2009 at 6:39 PM, Keith Packard wrote:
> Excerpts from Alan Coopersmith's message of Mon Sep 28 14:08:07 -0700 2009:
>
>> If they're really internal only, should they be marked _X_HIDDEN
>> to keep them from being abused by misguided modules?
>
> How about _X_INTERNAL?
>
> From 1c9c89299c806c0687a1d724452f73a293f5f2f2 Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 28 Sep 2009 12:39:47 -0700
> Subject: [PATCH] Re-fix DGA removal.
>
> Removing DGA ended up breaking any drivers calling into the old
> xf86DiDGAInit function as it tried to see if DGA was already enabled
> and ended up crashing if the VT wasn't completely initialized. Oops.
>
> Signed-off-by: Keith Packard
> ---
> hw/xfree86/modes/xf86Crtc.c | 4 ++--
> hw/xfree86/modes/xf86Crtc.h | 8
> hw/xfree86/modes/xf86DiDGA.c | 15 ---
> 3 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
> index 899cea5..4f31511 100644
> --- a/hw/xfree86/modes/xf86Crtc.c
> +++ b/hw/xfree86/modes/xf86Crtc.c
> @@ -770,7 +770,7 @@ xf86CrtcScreenInit (ScreenPtr screen)
> screen->CloseScreen = xf86CrtcCloseScreen;
>
> #ifdef XFreeXDGA
> - xf86DiDGAInit(screen, 0);
> + _xf86_di_dga_init_for_reals(screen);
> #endif
> #ifdef RANDR_13_INTERFACE
> return RANDR_INTERFACE_VERSION;
> @@ -1887,7 +1887,7 @@ xf86SetScrnInfoModes (ScrnInfoPtr scrn)
> scrn->currentMode = scrn->modes;
> #ifdef XFreeXDGA
> if (scrn->pScreen)
> - xf86DiDGAReInit(scrn->pScreen);
> + _xf86_di_dga_reinit_for_reals(scrn->pScreen);
> #endif
> }
>
> diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
> index 0a596bc..0f79066 100644
> --- a/hw/xfree86/modes/xf86Crtc.h
> +++ b/hw/xfree86/modes/xf86Crtc.h
> @@ -807,6 +807,10 @@ xf86OutputGetEDID (xf86OutputPtr output, I2CBusPtr
> pDDCBus);
> Bool
> xf86DiDGAInit (ScreenPtr pScreen, unsigned long dga_address);
>
> +/* this is the real function, used only internally */
> +_X_INTERNAL Bool
> +_xf86_di_dga_init_for_reals (ScreenPtr pScreen);
> +
> /**
> * Re-initialize dga for this screen (as when the set of modes changes)
> */
> @@ -814,6 +818,10 @@ xf86DiDGAInit (ScreenPtr pScreen, unsigned long
> dga_address);
> Bool
> xf86DiDGAReInit (ScreenPtr pScreen);
>
> +/* This is the real function, used only internally */
> +_X_INTERNAL Bool
> +_xf86_di_dga_reinit_for_reals (ScreenPtr pScreen);
> +
> /*
> * Set the su
Re: [Q] Xorg VNC driver?
On Sep 23, 09 14:33:24 -0500, Pat Kane wrote: > On Wed, Sep 23, 2009 at 8:46 AM, Matthias Hopf wrote: > > Sorry, porting was only to 1.6.3.901 (just noted that). However, they > > will probably a good start. > They provide a very good staring point and have saved me a lot of > work, thank you. > > I think the the mouse init code, init.c, needs to look somthing like > the attached snippet > of code (sorry I can not make patches yet). Does that look right? It doesn't look wrong (though I'm unsure how z axis i.e. mouse wheel is handled, and in the code I can only see handling of 3 buttons and 2 axes), but I'm not exactly fluent in that area. I did the port without too much thinking, and was happy that it actually worked with 1.6.3.901... CU Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XbkGetControls() fails...
On Sep 24, 09 15:37:58 +1000, Peter Hutterer wrote: > On Wed, Sep 23, 2009 at 03:16:38PM +0200, Matthias Hopf wrote: > > With the current Xserver XbkGetControls() fails with XkbBadKeyboard. > Tricky. xkb.device_spec is 0, which used to be the core keyboard (up to > 1.5). Now 0 is a reserved ID. If you add That explains everything. >xkb.device_spec = XkbUseCoreKbd; > before the call it picks the right keyboard. Strictly speaking, the code > sample was never valid, it just happened to work. > > Is this one of your test programs or a client that actually failed? Just a test program for printing out accessibility settings (I couldn't find *anything* in the X suite, so I coded up my own, because something in modern desktops always turned XkbAccessXKeysMask on, even though we wanted to have it off by default). Given that I had no clue of the whole subsystem it's fascinating I ever got it to work :-) Thanks a lot Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
Hi, On Tue, 2009-09-29 at 12:28 -0300, Lucas Mocellin wrote: > ah, and I will use firefox. the page that firefox will open is a > Moodle (moodle.org) and there are multimedia stuff (audio, videos, > flash) > > On Tue, Sep 29, 2009 at 11:55 AM, Lucas Mocellin > wrote: > I have 2 programs(my GUI + firefox) for normal users "manage", > they will get lost without a WM. I want to be light but very > user-friendly. Simple to use. > > A kiosk sounds interesting to me, I had never heard about that > berfore. Firefox has an add-on, and works quite well. > > The problem is that I can't "set it up", I mean, firefox runs > in fullscreen, and what about my GUI? even though ALT + TAB > works, normal users won't know how to use it. I don't have a > panel like "window list applet" in gnome. ( *MAYBE* I could > design a GTK interface acting as a panel located on the top > and the option "always on top", what do you guys think > about? ) > > Also, I need a button to shutdown/restart. (that could be > located at that gtk panel). > > I'm looking at Linux kiosk and twm-kiosk, trying to compile > and test it. but looks like it will work to me. Have a look at matchbox: http://matchbox-project.org/ Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
ah, and I will use firefox. the page that firefox will open is a Moodle ( moodle.org) and there are multimedia stuff (audio, videos, flash) On Tue, Sep 29, 2009 at 11:55 AM, Lucas Mocellin wrote: > I have 2 programs(my GUI + firefox) for normal users "manage", they will > get lost without a WM. I want to be light but very user-friendly. Simple to > use. > > A kiosk sounds interesting to me, I had never heard about that berfore. > Firefox has an add-on, and works quite well. > > The problem is that I can't "set it up", I mean, firefox runs in > fullscreen, and what about my GUI? even though ALT + TAB works, normal users > won't know how to use it. I don't have a panel like "window list applet" in > gnome. ( *MAYBE* I could design a GTK interface acting as a panel located on > the top and the option "always on top", what do you guys think about? ) > > Also, I need a button to shutdown/restart. (that could be located at that > gtk panel). > > I'm looking at Linux kiosk and twm-kiosk, trying to compile and test it. > but looks like it will work to me. > > thanks, > > Lucas. > > > On Tue, Sep 29, 2009 at 10:11 AM, Ross Burton wrote: > >> On Tue, 2009-09-29 at 09:23 -0300, Lucas Mocellin wrote: >> > defining light: it is supposed to run in most available (old and new) >> > hardware - at least 256MB. >> > >> > defining secure: I will show the Window Manager with an GUI on it, >> > this GUI will open the Firefox. Just it. I must avoid users to >> > accessing shell, quitting X and everything else. The minimun >> > resolution is 800x600. >> >> The Matchbox window manager sounds perfect for this. >> >> Ross >> >> -- >> Ross Burton mail: r...@burtonini.com >> jabber: r...@burtonini.com >> www: http://burtonini.com >> >> >> ___ >> xorg mailing list >> xorg@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg >> > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Intel 2009Q3 release
Dear Alan, yeah, knew their article and the "mess situation". I was just poking in the hope of progress, good news. Greetings, On 29.09.2009, at 16:55, Alan Coopersmith wrote: > Rene Rebe wrote: >> Where can the support for GMA500 aka as Poulsbo be found? > > http://www.phoronix.com/scan.php?page=search&q=Poulsbo > > -- > -Alan Coopersmith- alan.coopersm...@sun.com >Sun Microsystems, Inc. - X Window System Engineering -- René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.name ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Intel 2009Q3 release
Rene Rebe wrote: > Where can the support for GMA500 aka as Poulsbo be found? http://www.phoronix.com/scan.php?page=search&q=Poulsbo -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
I have 2 programs(my GUI + firefox) for normal users "manage", they will get lost without a WM. I want to be light but very user-friendly. Simple to use. A kiosk sounds interesting to me, I had never heard about that berfore. Firefox has an add-on, and works quite well. The problem is that I can't "set it up", I mean, firefox runs in fullscreen, and what about my GUI? even though ALT + TAB works, normal users won't know how to use it. I don't have a panel like "window list applet" in gnome. ( *MAYBE* I could design a GTK interface acting as a panel located on the top and the option "always on top", what do you guys think about? ) Also, I need a button to shutdown/restart. (that could be located at that gtk panel). I'm looking at Linux kiosk and twm-kiosk, trying to compile and test it. but looks like it will work to me. thanks, Lucas. On Tue, Sep 29, 2009 at 10:11 AM, Ross Burton wrote: > On Tue, 2009-09-29 at 09:23 -0300, Lucas Mocellin wrote: > > defining light: it is supposed to run in most available (old and new) > > hardware - at least 256MB. > > > > defining secure: I will show the Window Manager with an GUI on it, > > this GUI will open the Firefox. Just it. I must avoid users to > > accessing shell, quitting X and everything else. The minimun > > resolution is 800x600. > > The Matchbox window manager sounds perfect for this. > > Ross > > -- > Ross Burton mail: r...@burtonini.com > jabber: r...@burtonini.com > www: http://burtonini.com > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Compiler warnings unnecessarily caused by X11 headers
Hi,
it may be useful to compile programs with
gcc -Wall -Wwrite-strings -Wcast-qual
but unfortunately doing this causes numerous compiler warnings when defining
X11 resources. Attached is a small example resulting in 13 warnings
8 initialization discards qualifiers...
5 cast discards qualifiers...
All this is due to struct members declared as 'char *' or (char *) casts,
that actually should be 'const char *' or maybe '_Xconst char *'.
I'd think that it is about time to make these changes (knowing well that
they will imply corresponding changes in many other declarations).
Doing this right will, however, also be a good check that these string are
not modified by the X11 library code.
Regards
Peter Breitenlohner /* compile with:
* gcc -O2 -Wall -Wwrite-strings -Wcast-qual -c play.c
*/
#include
#include
#include
extern XtResource mf_resources[];
extern XrmOptionDescRec mf_optiondesclist[];
static unsigned int mf_defwidth = 0;
typedef struct
{
unsigned int mf_width;
Pixel mf_fg;
} mf_resources_struct;
XtResource mf_resources[] = { {
"width", /* initialization discards qualifiers... */
"Width", /* initialization discards qualifiers... */
XtRInt, /* cast discards qualifiers... */
sizeof (int),
XtOffset (mf_resources_struct *, mf_width),
XtRInt, /* cast discards qualifiers... */
(XtPointer) & mf_defwidth
}, {
"foreground", /* initialization discards qualifiers... */
"Foreground", /* initialization discards qualifiers... */
XtRPixel, /* cast discards qualifiers... */
sizeof (Pixel),
XtOffset (mf_resources_struct *, mf_fg),
XtRString,/* cast discards qualifiers... */
(XtPointer) "Black" /* initialization discards qualifiers... */
} };
XrmOptionDescRec mf_optiondesclist[] = { {
"-width", /* initialization discards qualifiers... */
"width", /* initialization discards qualifiers... */
XrmoptionSepArg,
(XPointer) NULL
}, {
"-fg",/* initialization discards qualifiers... */
"foreground", /* initialization discards qualifiers... */
XrmoptionSepArg,
(XPointer) NULL
} };
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
On Tue, 2009-09-29 at 09:23 -0300, Lucas Mocellin wrote: > defining light: it is supposed to run in most available (old and new) > hardware - at least 256MB. > > defining secure: I will show the Window Manager with an GUI on it, > this GUI will open the Firefox. Just it. I must avoid users to > accessing shell, quitting X and everything else. The minimun > resolution is 800x600. The Matchbox window manager sounds perfect for this. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
2009/9/29 Lucas Mocellin : > Hi, > > thanks for the answers, > > I'm sorry to not being clear, let's try again. > > the LiveCD customization must be 2 main things, secure and light: > > defining light: it is supposed to run in most available (old and new) > hardware - at least 256MB. > > defining secure: I will show the Window Manager with an GUI on it, this GUI > will open the Firefox. Why bother with a window manager at all then? Just run firefox and your gui bare, directly on X. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
Hi Lucas, > defining secure: I will show the Window Manager with an GUI on it, this GUI > will open the Firefox. Just it. I must avoid users to accessing shell, > quitting X and everything else. The minimun resolution is 800x600. Perhaps you can get away without a window manager at all? Not really sure how that works though. Also, if you want something to browse the web, but not do anything else, perhap you can use uzbl instead of firefox. It's a minimalistic browser that does not offer fancy stuff like firefox (which can probably be misused to do other stuff that you don't want). Even then, it might still not be 100% secure, but probably a lot closer. Gr. Matthijs signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How X works / lightest Window Manager
Hi, thanks for the answers, I'm sorry to not being clear, let's try again. the LiveCD customization must be 2 main things, secure and light: defining light: it is supposed to run in most available (old and new) hardware - at least 256MB. defining secure: I will show the Window Manager with an GUI on it, this GUI will open the Firefox. Just it. I must avoid users to accessing shell, quitting X and everything else. The minimun resolution is 800x600. btw, this LiveCD is an project from my university to perform online tests for distance learning. It will be open source and free in the end. =) thanks again folks. Lucas. On Tue, Sep 29, 2009 at 2:39 AM, Kai-Uwe Behrmann wrote: > Did you try the Xorg included twm? Twm itself uses few resources. > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management www.behrmann.name + www.oyranos.org > > > Am 28.09.09, 17:58 -0700 schrieb Tony Bones: > > should check out EvilWM. Besides being EVIL its also very light ;) >> > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: GMA 4500MHD
On Thu, Sep 24, 2009 at 01:54:57PM +0300, Stan Goodman wrote: > At 10:06:12 on Thursday Thursday 24 September 2009, Tomasz Torcz > wrote: > > On Thu, Sep 24, 2009 at 02:48:00AM +0300, Stan Goodman wrote: > > > At 01:30:27 on Thursday Thursday 24 September 2009, Miguel Angel > > > > > > wrote: > > > > There is, the intel driver has support to it: > > > > http://intellinuxgraphics.org/documentation.html > > > > > > I see there only GMA950. > > > > > > Actually, what I meant, perhaps out of misunderstanding of the > > > content of this group, is: Does the xorg-x11-driver-video-intel > > > package support the GMA 4500MHD graphics card? > > > > Of course, it is supported for many months now. > > Many thanks; that is what I wanted to know. > > I don't know why it is "of course". It isn't so easy to find out, when I > haven't bought the machine yet, so there is no way to experiment. Source code for Intel driver and Mesa is widely available. Support for chip you are asking for was added in June 2008: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=1cfe769c74d1a3a392bf1aaaf5c2dcc8273daf66 It was noted in 2.4.0 driver release announcement: http://lists.freedesktop.org/archives/xorg-announce/2008-July/000621.html which is linked form intellinuxgraphics.org frontpage: “2008-7-23:xf86-video-intel 2.4.0 released, with new Intel 4 series chipset support, improved 965 exa render performance, integrated HDMI support, and SDVO HDMI support.” For resolving GMA4500MHD↔G45 mapping you can look into Wikipedia: http://en.wikipedia.org/wiki/Intel_GMA#GMA_X4500 Hope that clears the confusion. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] Intel 2009Q3 release
Hi, On 29.09.2009, at 08:39, Jin, Gordon wrote: > Hi, > > We'd like to announce Intel 2009Q3 release package > (http://intellinuxgraphics.org/2009Q3.html > ), which consists of: > - xf86-video-intel 2.9.0 (released today) > - mesa 7.6 (released today) > - libdrm 2.4.14 > - Linux kernel 2.6.31.1 (Advanced users could try newer 2.6.32-ish > kernel and welcome to report regression) > - xserver 1.6.4 is recommended to use with this release > > This quarterly release is more like a bug fix cycle and no many new > features compared with 2009Q2 release. We expect this release > provide better stability than before, and would recommend OS > distributions and users to upgrade to this one. See the detailed > major fixes and known issues in the above webpage. > > KMS (Kernel Mode Setting) is strongly recommended to use in this > release. > > It'll be appreciated to file bugs referring to > http://intellinuxgraphics.org/how_to_report_bug.html > , if you see any unknown issues. Where can the support for GMA500 aka as Poulsbo be found? > Thanks, > Gordon > Intel Open Source Technology Center -- René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.name ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: [ANNOUNCE] Intel 2009Q3 release
Rene Rebe wrote on Tuesday, September 29, 2009 3:51 PM: > Hi, > > On 29.09.2009, at 08:39, Jin, Gordon wrote: > >> Hi, >> >> We'd like to announce Intel 2009Q3 release package >> (http://intellinuxgraphics.org/2009Q3.html ), which consists of: >> - xf86-video-intel 2.9.0 (released today) >> - mesa 7.6 (released today) >> - libdrm 2.4.14 >> - Linux kernel 2.6.31.1 (Advanced users could try newer 2.6.32-ish >> kernel and welcome to report regression) >> - xserver 1.6.4 is recommended to use with this release >> >> This quarterly release is more like a bug fix cycle and no many new >> features compared with 2009Q2 release. We expect this release >> provide better stability than before, and would recommend OS >> distributions and users to upgrade to this one. See the detailed >> major fixes and known issues in the above webpage. >> >> KMS (Kernel Mode Setting) is strongly recommended to use in this >> release. >> >> It'll be appreciated to file bugs referring to >> http://intellinuxgraphics.org/how_to_report_bug.html , if you see >> any unknown issues. > > Where can the support for GMA500 aka as Poulsbo be found? It's not supported by our open source intel driver yet. I don't have more details on that hardware. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
