Re: Subject: [PATCH 1/1] XSELinux: When SELinux is enabled the xserver seg faults
Hi,
Looks good to me, although I thought this was handled at the callsites. I
guess some callsites have been added or changed that pass in the special
ID's.
Acked-by: Eamon Walsh
On Tue, Jun 12, 2012 at 9:49 AM, Richard Haines <
richard_c_hai...@btinternet.com> wrote:
> This patch was created using xorg-server-1.12.0 source.
>
> When using Fedora 17 with xorg-server-1.12.0 and SELinux is enabled
> ('setsebool xserver_object_manager on') the xserver will not load. The X
> log file has a seg fault pointing to XACE/SELinux. Bug 50641 was raised
> (https://bugs.freedesktop.org/show_bug.cgi?id=50641). The patch below is a
> possible fix.
>
> The bug is caused by X calling XaceHook(XACE_DEVICE_ACCESS, client, ...)
> with a device ID of '1' that is XIAllMasterDevices. It would also happen
> if the device ID = 0 (XIAllDevices).
>
> The only places currently seen calling with a device id=1 are:
> GrabKey - in Xi/exevents.c and AddPassiveGrabToList - in dix/grabs.c
> These start life in ProcXIPassiveGrabDevice (in Xi/xipassivegrab.c) that
> has been called by XIGrabKeycode.
>
> The patch has been tested using the other XI calls that would also impact
> this: XIGrabTouchBegin, XIGrabButton, XIGrabFocusIn and XIGrabEnter with
> and without the correct permissions (grab and freeze) with no problems.
>
> Both possible classes have to be checked (x_keyboard and x_pointer) as it
> is not known whether it is a pointer or keyboard as this info is not
> available. To get this info would require a change to the
> XaceHook(XACE_DEVICE_ACCESS, client, ..) call to pass an additional
> parameter stating the actual devices (that would defeat the objective of
> the XIAllMasterDevices and XIAllDevices dev ids).
>
> Note that there are other devices apart from the keyboard and pointer, for
> example on the test system: DeviceID: 9 is the Integrated_Webcam_1.3M. As
> it is classed as a slave keyboard it is checked.
>
> Signed-off-by: Richard Haines
> ---
> Xext/xselinux_hooks.c | 44 +++-
> 1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/Xext/xselinux_hooks.c b/Xext/xselinux_hooks.c
> index 0d4c9ab..c2b21d6 100644
> --- a/Xext/xselinux_hooks.c
> +++ b/Xext/xselinux_hooks.c
> @@ -336,9 +336,17 @@ SELinuxDevice(CallbackListPtr *pcbl, pointer unused,
> pointer calldata)
> SELinuxAuditRec auditdata = { .client = rec->client, .dev = rec->dev };
> security_class_t cls;
> int rc;
> +DeviceIntPtr dev = NULL;
> +int i = 0;
>
> subj = dixLookupPrivate(&rec->client->devPrivates, subjectKey);
> -obj = dixLookupPrivate(&rec->dev->devPrivates, objectKey);
> + /*
> +* The XIAllMasterDevices or XIAllDevices do not have devPrivates
> +* entries. Therefore dixLookupPrivate for the object is done later
> +* for these device IDs.
> +*/
> + if (rec->dev->id != XIAllDevices && rec->dev->id !=
> XIAllMasterDevices)
> + obj = dixLookupPrivate(&rec->dev->devPrivates, objectKey);
>
> /* If this is a new object that needs labeling, do it now */
> if (rec->access_mode & DixCreateAccess) {
> @@ -356,12 +364,38 @@ SELinuxDevice(CallbackListPtr *pcbl, pointer unused,
> pointer calldata)
>}
> }
>
> -cls = IsPointerDevice(rec->dev) ? SECCLASS_X_POINTER :
> SECCLASS_X_KEYBOARD;
> -rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode, &auditdata);
> -if (rc != Success)
> - rec->status = rc;
> + if (rec->dev->id != XIAllDevices && rec->dev->id !=
> XIAllMasterDevices) {
> + cls = IsPointerDevice(rec->dev) ? SECCLASS_X_POINTER :
> SECCLASS_X_KEYBOARD;
> + rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode,
> &auditdata);
> + if (rc != Success)
> + rec->status = rc;
> + return;
> + } else {
> + /*
> +* Device ID must be 0 or 1
> +* We have to check both possible classes as we don't know
> whether it
> +* was a pointer or keyboard. Therefore all devices are
> checked for:
> +* rec->dev->id == XIAllDevices
> +* and only masters for:
> +* rec->dev->id == XIAllMasterDevices
> +*
> +* An error is returned should any device fail
> SELinuxDoCheck
> +*/
> + for (dev = inputInfo.devices; dev; dev = dev->next, i++) {
> + if (!IsMaster(dev) && rec->dev->id ==
> XIAllMasterDevices)
> + continue;
> + cls = IsPointerDevice(dev) ? SECCLASS_X_POINTER :
> SECCLASS_X_KEYBOARD;
> + obj = dixLookupPrivate(&dev->devPrivates,
> objectKey);
> + rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode,
> &auditdata);
> + if (rc != Success) {
> + rec->status = rc;
> +
Re: reentrancy of mieqProcessInputEvents()?
On Tue, Jun 12, 2012 at 05:11:49PM -0700, Andy Ritger wrote:
> Is mi/mieq.c:mieqProcessInputEvents() expected to be reentrant? Or should
> mieqProcessInputEvents() never be called in that situation?
>
> More specifically, is there a reason that the 'event' local variable in
> mieqProcessInputEvents() is declared static?
>
> static InternalEvent event;
I don't think so, this doesn't look right. looking at the log this was added
in xorg-server-1.5.99.1-136-ga939368 to avoid calloc but you're certainly
right, it breaks reentrancy. Following the history of that, it's not even
needed anymore, this came from a time when we had to callloc a list of
devices - now we can have just have one InternalEvent on the stack.
see more below though.
> Consider the following sequence:
>
> (a) User hits ctrl-alt-+ to do an old-school mode switch, and the keyboard
> event is put on the event queue.
>
> (b) mieqProcessInputEvents() pops the keyboard event from the event queue,
> storing the event data in a static local variable, and then passing a
> pointer to that variable into mieqProcessDeviceEvent():
>
> mieqProcessInputEvents(void)
> {
> [...]
> static InternalEvent event;
> [...]
> while (miEventQueue.head != miEventQueue.tail) {
> e = &miEventQueue.events[miEventQueue.head];
>
> event = *e->events;
> [...]
> mieqProcessDeviceEvent(dev, &event, screen);
> [...]
> }
>
> (c) The event pointer gets passed through several functions until we
> hit XkbHandleActions():
>
> #34 0x00585596 in XkbHandleActions (dev=0x1176370, kbd=0x1176370,
> event=0x85cf00) at xkbActions.c:1234
> #35 0x005865d8 in XkbProcessKeyboardEvent (event=0x85cf00,
> keybd=0x1176370) at xkbPrKeyEv.c:146
> #36 0x0057ad28 in AccessXFilterPressEvent (event=0x85cf00,
> keybd=0x1176370) at xkbAccessX.c:569
> #37 0x0058678e in ProcessKeyboardEvent (ev=0x85cf00, keybd=0x1176370)
> at xkbPrKeyEv.c:181
> #38 0x005aec39 in mieqProcessDeviceEvent (dev=0x1176370,
> event=0x85cf00, screen=0xaa49e0) at mieq.c:557
> #39 0x005aee75 in mieqProcessInputEvents () at mieq.c:624
> #40 0x0048adb9 in ProcessInputEvents () at xf86Events.c:164
> #41 0x00430835 in Dispatch () at dispatch.c:353
> #42 0x00421a45 in main (argc=1, argv=0x7fff049880d8,
> envp=0x7fff049880e8) at main.c:288
>
> (d) XkbHandleActions() will look at the event type to decide it is a
> keyEvent type, query the key action type, perform some operation based
> on the key action type, then pass the event into FixKeyState():
>
> void
> XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr kbd, DeviceEvent *event)
> {
> [...]
> keyEvent = ((event->type == ET_KeyPress) || (event->type ==
> ET_KeyRelease));
> [...]
> act = XkbGetKeyAction(xkbi, &xkbi->state, key);
> [...]
> switch (act.type) {
> [...]
> case XkbSA_XFree86Private:
> filter = _XkbNextFreeFilter(xkbi);
> sendEvent = _XkbFilterXF86Private(xkbi, filter, key, &act);
> break;
> }
> }
> [...]
> if (keyEvent) {
> FixKeyState(event, dev);
> }
> [...]
> }
>
> (e) FixKeyState() does this:
>
> if (event->type == ET_KeyPress)
> set_key_down(keybd, key, KEY_PROCESSED);
> else if (event->type == ET_KeyRelease)
> set_key_up(keybd, key, KEY_PROCESSED);
> else
> FatalError("Impossible keyboard event");
>
> (that will be important later...)
>
> (f) Back in XkbHandleActions(), we called _XkbFilterXF86Private which
> passes the key event to the XFree86 layer, which decodes the key event as
> "+vmode", and we call through the pScrnInfo->SwitchMode wrap chain:
>
> #6 0x004df525 in xf86CursorSwitchMode (index=0, mode=0x1c54eb0,
> flags=0) at xf86Cursor.c:253
> #7 0x00496ef1 in CMapSwitchMode (index=0, mode=0x1c54eb0, flags=0)
> at xf86cmap.c:492
> #8 0x00485fb1 in xf86SwitchMode (pScreen=0x1c40c00, mode=0x1c54eb0)
> at xf86Cursor.c:232
> #9 0x004863f8 in xf86ZoomViewport (pScreen=0x1c40c00, zoom=1) at
> xf86Cursor.c:332
> #10 0x0048ae8e in xf86ProcessActionEvent (action=ACTION_NEXT_MODE,
> arg=0x0) at xf86Events.c:191
> #11 0x004eb36c in XkbDDXPrivate (dev=0x22ac580, key=86 'V',
> act=0x78e60770) at xkbPrivate.c:32
> #12 0x00584746 in _XkbFilterXF86Private (xkbi=0x22ad470,
> filter=0x2265400, keycode=86,
> pAction=0x78e60770) at xkbActions.c:959
> #13 0x00585596 in XkbHandleActions (dev=0x22ac580, kbd=0x22ac580,
> event=0x85cf00)
> at xkbActions.c:1234
>
> (g) Someone in the pScrnInfo->SwitchMode wrap chain calls RRTellChanged()
> (in my case, it is the NVIDIA X driver, but I think many
> drivers could be exposed to this thr
Re: reentrancy of mieqProcessInputEvents()?
Andy Ritger writes: > Is mi/mieq.c:mieqProcessInputEvents() expected to be reentrant? Or should > mieqProcessInputEvents() never be called in that situation? It should never be re-entered; probably would be a good idea to check for that and whinge loudly in the log. > (g) Someone in the pScrnInfo->SwitchMode wrap chain calls RRTellChanged() > (in my case, it is the NVIDIA X driver, but I think many > drivers could be exposed to this through xf86SetSingleMode() -> > xf86RandR12TellChanged()) which calls UpdateCurrentTime(). This function needs to use UpdateCurrentTimeIf to avoid recursing. > Making the 'event' variable in mieqProcessInputEvents() non-static > avoids the FatalError() in FixKeyState(), but is it problematic to > have the re-entered instance of mieqProcessInputEvents() process events > from miEventQueue before the first instance of mieqProcessInputEvents() > has completed processing of its current event? Yeah, that's not a good plan. -- keith.pack...@intel.com pgpa6PxNAGubt.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
reentrancy of mieqProcessInputEvents()?
Is mi/mieq.c:mieqProcessInputEvents() expected to be reentrant? Or should
mieqProcessInputEvents() never be called in that situation?
More specifically, is there a reason that the 'event' local variable in
mieqProcessInputEvents() is declared static?
static InternalEvent event;
Consider the following sequence:
(a) User hits ctrl-alt-+ to do an old-school mode switch, and the keyboard
event is put on the event queue.
(b) mieqProcessInputEvents() pops the keyboard event from the event queue,
storing the event data in a static local variable, and then passing a
pointer to that variable into mieqProcessDeviceEvent():
mieqProcessInputEvents(void)
{
[...]
static InternalEvent event;
[...]
while (miEventQueue.head != miEventQueue.tail) {
e = &miEventQueue.events[miEventQueue.head];
event = *e->events;
[...]
mieqProcessDeviceEvent(dev, &event, screen);
[...]
}
(c) The event pointer gets passed through several functions until we
hit XkbHandleActions():
#34 0x00585596 in XkbHandleActions (dev=0x1176370, kbd=0x1176370,
event=0x85cf00) at xkbActions.c:1234
#35 0x005865d8 in XkbProcessKeyboardEvent (event=0x85cf00,
keybd=0x1176370) at xkbPrKeyEv.c:146
#36 0x0057ad28 in AccessXFilterPressEvent (event=0x85cf00,
keybd=0x1176370) at xkbAccessX.c:569
#37 0x0058678e in ProcessKeyboardEvent (ev=0x85cf00, keybd=0x1176370)
at xkbPrKeyEv.c:181
#38 0x005aec39 in mieqProcessDeviceEvent (dev=0x1176370,
event=0x85cf00, screen=0xaa49e0) at mieq.c:557
#39 0x005aee75 in mieqProcessInputEvents () at mieq.c:624
#40 0x0048adb9 in ProcessInputEvents () at xf86Events.c:164
#41 0x00430835 in Dispatch () at dispatch.c:353
#42 0x00421a45 in main (argc=1, argv=0x7fff049880d8,
envp=0x7fff049880e8) at main.c:288
(d) XkbHandleActions() will look at the event type to decide it is a
keyEvent type, query the key action type, perform some operation based
on the key action type, then pass the event into FixKeyState():
void
XkbHandleActions(DeviceIntPtr dev, DeviceIntPtr kbd, DeviceEvent *event)
{
[...]
keyEvent = ((event->type == ET_KeyPress) || (event->type ==
ET_KeyRelease));
[...]
act = XkbGetKeyAction(xkbi, &xkbi->state, key);
[...]
switch (act.type) {
[...]
case XkbSA_XFree86Private:
filter = _XkbNextFreeFilter(xkbi);
sendEvent = _XkbFilterXF86Private(xkbi, filter, key, &act);
break;
}
}
[...]
if (keyEvent) {
FixKeyState(event, dev);
}
[...]
}
(e) FixKeyState() does this:
if (event->type == ET_KeyPress)
set_key_down(keybd, key, KEY_PROCESSED);
else if (event->type == ET_KeyRelease)
set_key_up(keybd, key, KEY_PROCESSED);
else
FatalError("Impossible keyboard event");
(that will be important later...)
(f) Back in XkbHandleActions(), we called _XkbFilterXF86Private which
passes the key event to the XFree86 layer, which decodes the key event as
"+vmode", and we call through the pScrnInfo->SwitchMode wrap chain:
#6 0x004df525 in xf86CursorSwitchMode (index=0, mode=0x1c54eb0,
flags=0) at xf86Cursor.c:253
#7 0x00496ef1 in CMapSwitchMode (index=0, mode=0x1c54eb0, flags=0) at
xf86cmap.c:492
#8 0x00485fb1 in xf86SwitchMode (pScreen=0x1c40c00, mode=0x1c54eb0) at
xf86Cursor.c:232
#9 0x004863f8 in xf86ZoomViewport (pScreen=0x1c40c00, zoom=1) at
xf86Cursor.c:332
#10 0x0048ae8e in xf86ProcessActionEvent (action=ACTION_NEXT_MODE,
arg=0x0) at xf86Events.c:191
#11 0x004eb36c in XkbDDXPrivate (dev=0x22ac580, key=86 'V',
act=0x78e60770) at xkbPrivate.c:32
#12 0x00584746 in _XkbFilterXF86Private (xkbi=0x22ad470,
filter=0x2265400, keycode=86,
pAction=0x78e60770) at xkbActions.c:959
#13 0x00585596 in XkbHandleActions (dev=0x22ac580, kbd=0x22ac580,
event=0x85cf00)
at xkbActions.c:1234
(g) Someone in the pScrnInfo->SwitchMode wrap chain calls RRTellChanged()
(in my case, it is the NVIDIA X driver, but I think many
drivers could be exposed to this through xf86SetSingleMode() ->
xf86RandR12TellChanged()) which calls UpdateCurrentTime().
(h) UpdateCurrentTime() conditionally calls ProcessInputEvents():
void
UpdateCurrentTime(void)
{
[...]
if (*checkForInput[0] != *checkForInput[1])
ProcessInputEvents();
[...]
}
---
void
ProcessInputEvents(void)
{
int x, y;
mieqProcessInputEvents();
/* FIXME: This is a problem if we have multiple pointers */
miPointerGetPosition(inputInfo.pointer, &x, &y);
xf86SetViewport(xf86Info.currentScreen, x, y);
}
(i) checkForInput[0] and [1] point to miEventQueue.{head,tai
Re: [PATCH 4/4] glx: Reject creations of indirect contexts with unsupportable versions.
On 06/10/2012 11:13 AM, Dave Airlie wrote:
On Fri, Jun 8, 2012 at 9:10 PM, Ian Romanick wrote:
From: Ian Romanick
Signed-off-by: Ian Romanick
Looks like a piglit test for this would be good, if there isn't one,
if there is it would be good to mention it.
I've been putting together some piglit tests for
GLX_ARB_create_context_profile and GLX_EXT_create_context_es2_profile.
These should go out to the piglit list today.
One difficulty with this particular change is that a vendor could,
hypothetically, make their protocol for later GL versions. I believe
that NVIDIA has protocol for up to 2.1 and possibly later. In that
case, creating an indirect rendering context would succeed.
but it looks fine,
Reviewed-by: Dave Airlie
---
glx/createcontext.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/glx/createcontext.c b/glx/createcontext.c
index 8f7dc05..4a6e1b5 100644
--- a/glx/createcontext.c
+++ b/glx/createcontext.c
@@ -270,6 +270,23 @@ __glXDisp_CreateContextAttribsARB(__GLXclientState * cl,
GLbyte * pc)
return __glXError(GLXBadProfileARB);
}
+/* There is no GLX protocol for desktop OpenGL versions after 1.4. There
+ * is no GLX protocol for any version of OpenGL ES. If the application is
+ * requested an indirect rendering context for a version that cannot be
+ * satisfied, reject it.
+ *
+ * The GLX_ARB_create_context spec says:
+ *
+ * "* If does not support compatible OpenGL contexts
+ *providing the requested API major and minor version,
+ *forward-compatible flag, and debug context flag, GLXBadFBConfig
+ *is generated."
+ */
+if (!req->isDirect&& (major_version> 1 || minor_version> 4
+ || profile == GLX_CONTEXT_ES2_PROFILE_BIT_EXT)) {
+return __glXError(GLXBadFBConfig);
+}
+
/* Allocate memory for the new context
*/
if (req->isDirect) {
--
1.7.6.5
___
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 randrproto] Add a "GUID" property
This property represents the globally-unique identifier of the connected
display, if one is available.
Signed-off-by: Aaron Plattner
Reviewed-by: Andy Ritger
---
randr.h|1 +
randrproto.txt | 12
2 files changed, 13 insertions(+)
diff --git a/randr.h b/randr.h
index 9cb9403..53e2660 100644
--- a/randr.h
+++ b/randr.h
@@ -183,5 +183,6 @@ typedef unsigned long XRandrModeFlags;
#define RR_PROPERTY_CLONE_LIST "CloneList"
#define RR_PROPERTY_BORDER "Border"
#define RR_PROPERTY_BORDER_DIMENSIONS "BorderDimensions"
+#define RR_PROPERTY_GUID "GUID"
#endif /* _RANDR_H_ */
diff --git a/randrproto.txt b/randrproto.txt
index e90b1cd..2190540 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -1856,6 +1856,17 @@ doesn't handle a mandatory property correctly.
2 = left/right and top/bottom borders can be specified independently
4 = all four borders can be specified independently
+"GUID" aka RR_PROPERTY_GUID
+ Type: INTEGER
+ Format: 8
+ Num items: 16
+ Flags: Immutable
+ Range/List: -
+
+ Some display devices, such as DisplayPort 1.2 devices, have globally
+ unique identifiers. When such an identifier is available, this property
+ contains its raw bytes.
+
9.2 Properties introduced with version 1.2 of the RandR extension
@@ -1889,6 +1900,7 @@ Property Immutable Mandatory since
─ ───
Border yes not mandatory
BorderDimensions yes: static not mandatory
+GUID yes not mandatory
❧❧❧
--
1.7.9.5
___
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 xorg-server] Fix xf86EdidModes.c: array subscript is above array bounds
Using gcc with -O3 failes to compile the current version of
hw/xfree86/modes/xf86EdidModes.c.
With this optimization level gcc notices, that the loop in function
DDCModesFromEstIII() would go until i=5 and j=1 which would result in
m = (5 * 8) + (7 - 1) = 46, but the array EstIIIModes[] only contains
44 elements.
The following patch fixes this by adding 4 dummy elements to the array
so that for each 6 * 8 bits from the est_iii field a mode is defined.
Additionally the patch fixes the loop for (j = 7; j > 0; j--) to run
until 0, otherwise the last mode of each byte will always be skipped.
I had opened Bug https://bugs.freedesktop.org/show_bug.cgi?id=45623
for this and you can find the patch there too.
Signed-off-by: Torsten Kaiser
--- a/hw/xfree86/modes/xf86EdidModes.c.orig 2012-02-08 22:00:45.805914457
+0100
+++ b/hw/xfree86/modes/xf86EdidModes.c 2012-02-08 22:02:49.615915120 +0100
@@ -731,6 +731,11 @@
{ 1920, 1200, 85, 0 },
{ 1920, 1440, 60, 0 },
{ 1920, 1440, 75, 0 },
+/* fill up last byte */
+{ 0,0,0,0 },
+{ 0,0,0,0 },
+{ 0,0,0,0 },
+{ 0,0,0,0 },
};
static DisplayModePtr
@@ -740,10 +745,11 @@
int i, j, m;
for (i = 0; i < 6; i++) {
- for (j = 7; j > 0; j--) {
+ for (j = 7; j >= 0; j--) {
if (est[i] & (1 << j)) {
m = (i * 8) + (7 - j);
- modes = xf86ModesAdd(modes,
+ if (EstIIIModes[m].w)
+ modes = xf86ModesAdd(modes,
FindDMTMode(EstIIIModes[m].w,
EstIIIModes[m].h,
EstIIIModes[m].r,
___
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: No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 Rafał Miłecki : > 2012/6/11 Rafał Miłecki : >> I'm trying to switch from fbdev to modesetting for my AMD Southern >> Islands VERDE card. Of course I've KMS running just fine, radeon >> module loads and sets correct resolution, dmesg looks alright >> >> Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> the driver doesn't provide any screens/modes. It looks like this: >> (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> (WW) Falling back to old probe method for modesetting >> (II) UnloadModule: "modesetting" >> (II) Unloading modesetting >> (EE) Screen(s) found, but none have a usable configuration. >> >> Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> using xf86-video-modesetting from today's git. Any patch/trick to >> debug this issue? > > I don't think old X server is an issue here. The function to focus on > is probe_hw_pci. > > This function calls "open_hw" which opens /dev/dri/card0 and return fd > (9 in my case, irrelevant). Then comes the moment when probe_hw_pci > calls: > id = drmGetBusid(fd); > devid = ms_DRICreatePCIBusID(pdev); > > The first one returns NULL, the second one returns "pci::03:00.0". > As the "id" is NULL (empty string) probe_hw_pci returns false and the > rest fails. > > I can't say why drmGetBusid returns NULL. My drm is from yesterday's > git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. > Hacking probe_hw_pci to return TRUE allows me start X with > modesetting. I've hacked xf86drm.c::drmGetBusid to print some debugging messages. When we call "drmGetBusid" in "probe_hw_pci", u.unique_len gets 0 and u.unique gets "\0". However I've noticed there's one more call to "drmGetBusid". The stacktrace is: PreInit → drmOpen(NULL, BusID) → drmOpenByBusid → drmGetBusid In the above call, drmGetBusid gets u.unique_len gets 16 and u.unique gets "pci::03:00.0\0". Does it give you any hint what can happen here? -- Rafał ___ 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] intel/uxa: do copy fb at startup.
On Tue, Jun 12, 2012 at 3:20 PM, Chris Wilson wrote: > On Tue, 12 Jun 2012 10:26:34 +0100, Dave Airlie wrote: >> Copy the current framebuffer for smooth wayland->gdm handoff. >> >> This has been hanging around in Fedora for too long now, and we've >> dropped the feature a few times, and yes I know the Simpsons did it^W^W^W >> SNA does it. >> >> I've updated the code to have some of the better fixes from nouveau. > > I wasn't convinced that we needed to perform the copy on every VT > switch, so I dropped those chunks. If it is required, please could you > resubmit those with an explanation. Otherwise I fixed up the error > handling during intel_copy_fb() and pushed. Thanks. Now that you mention it I can see no reason for it either, it was just in the original patch, and I rebased it. but yeah it makes no sense, so thanks for dropping it. Now I just have to stop the my eDP panel flashing once on the plymouth->X transition, Dave. ___ 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: No screens after (WW) Falling back to old probe method for modesetting
2012/6/11 Rafał Miłecki : > I'm trying to switch from fbdev to modesetting for my AMD Southern > Islands VERDE card. Of course I've KMS running just fine, radeon > module loads and sets correct resolution, dmesg looks alright > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > the driver doesn't provide any screens/modes. It looks like this: > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > (WW) Falling back to old probe method for modesetting > (II) UnloadModule: "modesetting" > (II) Unloading modesetting > (EE) Screen(s) found, but none have a usable configuration. > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > using xf86-video-modesetting from today's git. Any patch/trick to > debug this issue? I don't think old X server is an issue here. The function to focus on is probe_hw_pci. This function calls "open_hw" which opens /dev/dri/card0 and return fd (9 in my case, irrelevant). Then comes the moment when probe_hw_pci calls: id = drmGetBusid(fd); devid = ms_DRICreatePCIBusID(pdev); The first one returns NULL, the second one returns "pci::03:00.0". As the "id" is NULL (empty string) probe_hw_pci returns false and the rest fails. I can't say why drmGetBusid returns NULL. My drm is from yesterday's git and DRM_IOCTL_GET_UNIQUE isn't something bleeding edge AFAIK. Hacking probe_hw_pci to return TRUE allows me start X with modesetting. -- Rafał ___ 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] intel/uxa: do copy fb at startup.
On Tue, 12 Jun 2012 10:26:34 +0100, Dave Airlie wrote: > Copy the current framebuffer for smooth wayland->gdm handoff. > > This has been hanging around in Fedora for too long now, and we've > dropped the feature a few times, and yes I know the Simpsons did it^W^W^W > SNA does it. > > I've updated the code to have some of the better fixes from nouveau. I wasn't convinced that we needed to perform the copy on every VT switch, so I dropped those chunks. If it is required, please could you resubmit those with an explanation. Otherwise I fixed up the error handling during intel_copy_fb() and pushed. Thanks. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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
Subject: [PATCH 1/1] XSELinux: When SELinux is enabled the xserver seg faults
This patch was created using xorg-server-1.12.0 source.
When using Fedora 17 with xorg-server-1.12.0 and SELinux is enabled
('setsebool xserver_object_manager on') the xserver will not load. The X
log file has a seg fault pointing to XACE/SELinux. Bug 50641 was raised
(https://bugs.freedesktop.org/show_bug.cgi?id=50641). The patch below is a
possible fix.
The bug is caused by X calling XaceHook(XACE_DEVICE_ACCESS, client, ...)
with a device ID of '1' that is XIAllMasterDevices. It would also happen
if the device ID = 0 (XIAllDevices).
The only places currently seen calling with a device id=1 are:
GrabKey - in Xi/exevents.c and AddPassiveGrabToList - in dix/grabs.c
These start life in ProcXIPassiveGrabDevice (in Xi/xipassivegrab.c) that
has been called by XIGrabKeycode.
The patch has been tested using the other XI calls that would also impact
this: XIGrabTouchBegin, XIGrabButton, XIGrabFocusIn and XIGrabEnter with
and without the correct permissions (grab and freeze) with no problems.
Both possible classes have to be checked (x_keyboard and x_pointer) as it
is not known whether it is a pointer or keyboard as this info is not
available. To get this info would require a change to the
XaceHook(XACE_DEVICE_ACCESS, client, ..) call to pass an additional
parameter stating the actual devices (that would defeat the objective of
the XIAllMasterDevices and XIAllDevices dev ids).
Note that there are other devices apart from the keyboard and pointer, for
example on the test system: DeviceID: 9 is the Integrated_Webcam_1.3M. As
it is classed as a slave keyboard it is checked.
Signed-off-by: Richard Haines
---
Xext/xselinux_hooks.c | 44 +++-
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/Xext/xselinux_hooks.c b/Xext/xselinux_hooks.c
index 0d4c9ab..c2b21d6 100644
--- a/Xext/xselinux_hooks.c
+++ b/Xext/xselinux_hooks.c
@@ -336,9 +336,17 @@ SELinuxDevice(CallbackListPtr *pcbl, pointer unused,
pointer calldata)
SELinuxAuditRec auditdata = { .client = rec->client, .dev = rec->dev };
security_class_t cls;
int rc;
+DeviceIntPtr dev = NULL;
+int i = 0;
subj = dixLookupPrivate(&rec->client->devPrivates, subjectKey);
-obj = dixLookupPrivate(&rec->dev->devPrivates, objectKey);
+ /*
+* The XIAllMasterDevices or XIAllDevices do not have devPrivates
+* entries. Therefore dixLookupPrivate for the object is done later
+* for these device IDs.
+*/
+ if (rec->dev->id != XIAllDevices && rec->dev->id != XIAllMasterDevices)
+ obj = dixLookupPrivate(&rec->dev->devPrivates, objectKey);
/* If this is a new object that needs labeling, do it now */
if (rec->access_mode & DixCreateAccess) {
@@ -356,12 +364,38 @@ SELinuxDevice(CallbackListPtr *pcbl, pointer unused,
pointer calldata)
}
}
-cls = IsPointerDevice(rec->dev) ? SECCLASS_X_POINTER : SECCLASS_X_KEYBOARD;
-rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode, &auditdata);
-if (rc != Success)
- rec->status = rc;
+ if (rec->dev->id != XIAllDevices && rec->dev->id != XIAllMasterDevices)
{
+ cls = IsPointerDevice(rec->dev) ? SECCLASS_X_POINTER :
SECCLASS_X_KEYBOARD;
+ rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode,
&auditdata);
+ if (rc != Success)
+ rec->status = rc;
+ return;
+ } else {
+ /*
+* Device ID must be 0 or 1
+* We have to check both possible classes as we don't know
whether it
+* was a pointer or keyboard. Therefore all devices are checked
for:
+* rec->dev->id == XIAllDevices
+* and only masters for:
+* rec->dev->id == XIAllMasterDevices
+*
+* An error is returned should any device fail SELinuxDoCheck
+*/
+ for (dev = inputInfo.devices; dev; dev = dev->next, i++) {
+ if (!IsMaster(dev) && rec->dev->id ==
XIAllMasterDevices)
+ continue;
+ cls = IsPointerDevice(dev) ? SECCLASS_X_POINTER :
SECCLASS_X_KEYBOARD;
+ obj = dixLookupPrivate(&dev->devPrivates, objectKey);
+ rc = SELinuxDoCheck(subj, obj, cls, rec->access_mode,
&auditdata);
+ if (rc != Success) {
+ rec->status = rc;
+ return;
+ }
+ }
+ }
}
+
static void
SELinuxSend(CallbackListPtr *pcbl, pointer unused, pointer calldata)
{
--
1.7.10.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: No screens after (WW) Falling back to old probe method for modesetting
- Original Message - > From: "Rafał Miłecki" > To: xorg-devel@lists.x.org, "dri-devel" , > "Dave Airlie" > Cc: "Alex Deucher" > Sent: Monday, 11 June, 2012 8:55:56 PM > Subject: Re: No screens after (WW) Falling back to old probe method for > modesetting > > 2012/6/11 Rafał Miłecki : > > I'm trying to switch from fbdev to modesetting for my AMD Southern > > Islands VERDE card. Of course I've KMS running just fine, radeon > > module loads and sets correct resolution, dmesg looks alright > > > > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU > > the driver doesn't provide any screens/modes. It looks like this: > > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so > > (WW) Falling back to old probe method for modesetting > > (II) UnloadModule: "modesetting" > > (II) Unloading modesetting > > (EE) Screen(s) found, but none have a usable configuration. > > > > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm > > using xf86-video-modesetting from today's git. Any patch/trick to > > debug this issue? > > Attaching Xorg.0.logs Try adding a BusID maybe, though I'm not sure how tested modesetting is with that old an X server. Dave. ___ 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] intel/uxa: do copy fb at startup.
On Tue, 12 Jun 2012 10:26:34 +0100, Dave Airlie wrote:
> Copy the current framebuffer for smooth wayland->gdm handoff.
>
> This has been hanging around in Fedora for too long now, and we've
> dropped the feature a few times, and yes I know the Simpsons did it^W^W^W
> SNA does it.
>
> I've updated the code to have some of the better fixes from nouveau.
>
> I've no idea who wrote this code either, krh or ajax.
Looks like it shouldn't in principle suffer from the false errors that
permeate the Ubuntu logs, though it still emits an X_ERROR for sane
failure modes.
> Signed-off-by: Dave Airlie
> ---
> +void intel_copy_fb(ScrnInfoPtr scrn)
> +{
> + xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
> + ScreenPtr pScreen = xf86ScrnToScreen(scrn);
> + intel_screen_private *intel = intel_get_screen_private(scrn);
> + PixmapPtr src, dst;
> + unsigned int pitch = scrn->displayWidth * intel->cpp;
> + struct intel_crtc *intel_crtc;
> + int i;
> + int fbcon_id = 0;
> + for (i = 0; i < xf86_config->num_crtc; i++) {
> + intel_crtc = xf86_config->crtc[i]->driver_private;
> + if (intel_crtc->mode_crtc->buffer_id)
> + fbcon_id = intel_crtc->mode_crtc->buffer_id;
> + }
> + if (!fbcon_id)
> + goto fallback;
> +
> + src = intel_create_pixmap_for_fbcon(scrn, fbcon_id);
> + if (src == NULL) {
> + xf86DrvMsg(scrn->scrnIndex, X_ERROR,
> +"Couldn't create pixmap for fbcon\n");
> + return;
> + }
> +
> + /* We dont have a screen Pixmap yet */
> + dst = GetScratchPixmapHeader(pScreen,
> + scrn->virtualX, scrn->virtualY,
> + scrn->depth, scrn->bitsPerPixel,
> + pitch,
> + NULL);
> + intel_set_pixmap_bo(dst, intel->front_buffer);
> +
> + intel->uxa_driver->prepare_copy(src, dst, -1, -1, GXcopy, FB_ALLONES);
> +
> + intel->uxa_driver->copy(dst, 0, 0, 0, 0,
> + scrn->virtualX, scrn->virtualY);
> +
> + intel->uxa_driver->done_copy(dst);
> +
> + /* I830EmitFlush(scrn); */
> + intel_batch_submit(scrn);
Should be handled by the flush during mode change.
> +
> + (*pScreen->DestroyPixmap)(src);
> + (*pScreen->DestroyPixmap)(dst);
We've broken the symmetry here between GetScratchPixmapHeader and
FreeScratchPixmapHeader. Instead of using GetScratchPixmapHeader
allocate a 0x0 pixmap and ModifyPixmapHeader. A little function to wrap
a bo into a pixmap would help here.
> +
> + pScreen->canDoBGNoneRoot = TRUE;
The prepare_copy could theoretically fail. So it needs error handling
and we need to let the core know that it needs to fill the background.
(Well, the conditions under which is could fail are likely fatal, but
there should at least be a check for a hung GPU somewhere in this path.)
> + return;
> +fallback:
> + return;
> +}
> diff --git a/src/intel_driver.c b/src/intel_driver.c
> index 67cec48..703c3a3 100644
> --- a/src/intel_driver.c
> +++ b/src/intel_driver.c
> @@ -83,6 +83,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
> static void i830AdjustFrame(ADJUST_FRAME_ARGS_DECL);
> static Bool I830CloseScreen(CLOSE_SCREEN_ARGS_DECL);
> static Bool I830EnterVT(VT_FUNC_ARGS_DECL);
> +static Bool I830EnterVT_copy(ScrnInfoPtr pScrn, Bool copy_fb);
>
> /* temporary */
> extern void xf86SetCursor(ScreenPtr screen, CursorPtr pCurs, int x, int y);
> @@ -167,6 +168,7 @@ static Bool i830CreateScreenResources(ScreenPtr screen)
> if (!(*screen->CreateScreenResources) (screen))
> return FALSE;
>
> + intel_copy_fb(scrn);
> return intel_uxa_create_screen_resources(screen);
> }
>
> @@ -1007,7 +1009,7 @@ I830ScreenInit(SCREEN_INIT_ARGS_DECL)
>* later memory should be bound when allocating, e.g rotate_mem */
> scrn->vtSema = TRUE;
>
> - return I830EnterVT(VT_FUNC_ARGS(0));
> + return I830EnterVT_copy(scrn, FALSE);
> }
>
> static void i830AdjustFrame(ADJUST_FRAME_ARGS_DECL)
> @@ -1048,9 +1050,8 @@ static void I830LeaveVT(VT_FUNC_ARGS_DECL)
> /*
> * This gets called when gaining control of the VT, and from ScreenInit().
> */
> -static Bool I830EnterVT(VT_FUNC_ARGS_DECL)
> +static Bool I830EnterVT_copy(ScrnInfoPtr scrn, Bool copy_fb)
> {
> - SCRN_INFO_PTR(arg);
> intel_screen_private *intel = intel_get_screen_private(scrn);
> int ret;
>
> @@ -1061,12 +1062,21 @@ static Bool I830EnterVT(VT_FUNC_ARGS_DECL)
> strerror(errno));
> }
>
> + if (copy_fb)
> + intel_copy_fb(scrn);
> +
> if (!xf86SetDesiredModes(scrn))
> return FALSE;
>
> return TRUE;
> }
>
> +static Bool I830EnterVT(VT_FUNC_ARGS_DECL)
> +{
> + SCRN_INFO_PTR(arg);
> + return I830EnterVT_copy(scrn, TRUE);
We only want to copy the initial fb on startup
Panning is broken in intel & nouveau but not radeon
https://bugs.freedesktop.org/show_bug.cgi?id=39949 Looks like it could use some help from anyone capable. It was reported 10 months ago. Usecase: I use CRTs to generate screenshots to assist in web site development troubleshooting. These are typically made to look like they were shot on 1920x1200, 1920x1080, 2048x1152 or 2560x1440 displays while actually running 1400x1050, 1600x1200 or 1920x1440 to generate them. Panel display support for such work is too limiting, and would require actually having and being connected to a physical panel supporting it for each wanted resolution, something highly impractical for most web development environments. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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: No screens after (WW) Falling back to old probe method for modesetting
2012/6/12 David Airlie : > - Original Message - >> From: "Rafał Miłecki" >> To: xorg-devel@lists.x.org, "dri-devel" , >> "Dave Airlie" >> Cc: "Alex Deucher" >> Sent: Monday, 11 June, 2012 8:55:56 PM >> Subject: Re: No screens after (WW) Falling back to old probe method for >> modesetting >> >> 2012/6/11 Rafał Miłecki : >> > I'm trying to switch from fbdev to modesetting for my AMD Southern >> > Islands VERDE card. Of course I've KMS running just fine, radeon >> > module loads and sets correct resolution, dmesg looks alright >> > >> > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU >> > the driver doesn't provide any screens/modes. It looks like this: >> > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so >> > (WW) Falling back to old probe method for modesetting >> > (II) UnloadModule: "modesetting" >> > (II) Unloading modesetting >> > (EE) Screen(s) found, but none have a usable configuration. >> > >> > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm >> > using xf86-video-modesetting from today's git. Any patch/trick to >> > debug this issue? >> >> Attaching Xorg.0.logs > > Try adding a BusID maybe, though I'm not sure how tested modesetting is with > that old an X server. I already have it added. It's weird modesetting doesn't put any message in Xorg.0.log, it has few messages printing in source. Will put some debugging in modesetting to see what actually happens. -- Rafał ___ 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] intel/uxa: do copy fb at startup.
Copy the current framebuffer for smooth wayland->gdm handoff.
This has been hanging around in Fedora for too long now, and we've
dropped the feature a few times, and yes I know the Simpsons did it^W^W^W
SNA does it.
I've updated the code to have some of the better fixes from nouveau.
I've no idea who wrote this code either, krh or ajax.
Signed-off-by: Dave Airlie
---
src/intel.h |1 +
src/intel_display.c | 110 +++
src/intel_driver.c | 16 ++--
3 files changed, 124 insertions(+), 3 deletions(-)
diff --git a/src/intel.h b/src/intel.h
index 20d8282..caf07bb 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -368,6 +368,7 @@ extern void intel_mode_fini(intel_screen_private *intel);
extern int intel_get_pipe_from_crtc_id(drm_intel_bufmgr *bufmgr, xf86CrtcPtr
crtc);
extern int intel_crtc_id(xf86CrtcPtr crtc);
extern int intel_output_dpms_status(xf86OutputPtr output);
+extern void intel_copy_fb(ScrnInfoPtr scrn);
enum DRI2FrameEventType {
DRI2_SWAP,
diff --git a/src/intel_display.c b/src/intel_display.c
index 6f3f7e6..c777435 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "xorgVersion.h"
@@ -45,6 +46,8 @@
#include "X11/Xatom.h"
#include "X11/extensions/dpmsconst.h"
#include "xf86DDC.h"
+#include "fb.h"
+#include "uxa.h"
#include "intel_glamor.h"
@@ -1748,3 +1751,110 @@ Bool intel_crtc_on(xf86CrtcPtr crtc)
return ret;
}
+
+static PixmapPtr
+intel_create_pixmap_for_fbcon(ScrnInfoPtr scrn, int fbcon_id)
+{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+ ScreenPtr pScreen = xf86ScrnToScreen(scrn);
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+ struct intel_mode *intel_mode = intel->modes;
+ drmModeFBPtr fbcon;
+ struct drm_gem_flink flink;
+ drm_intel_bo *bo;
+ PixmapPtr pixmap = NULL;
+ int i;
+
+ fbcon = drmModeGetFB(intel_mode->fd, fbcon_id);
+ if (fbcon == NULL)
+ return NULL;
+
+if (fbcon->depth != scrn->depth ||
+fbcon->width != scrn->virtualX ||
+fbcon->height != scrn->virtualY)
+goto out_free_fb;
+
+ flink.handle = fbcon->handle;
+ if (ioctl(intel_mode->fd, DRM_IOCTL_GEM_FLINK, &flink) < 0) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "Couldn't flink fbcon handle\n");
+ return NULL;
+ }
+
+ bo = drm_intel_bo_gem_create_from_name(intel->bufmgr,
+ "fbcon", flink.name);
+ if (bo == NULL) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "Couldn't allocate bo for fbcon handle\n");
+ return NULL;
+ }
+
+ pixmap = GetScratchPixmapHeader(pScreen,
+ fbcon->width, fbcon->height,
+ fbcon->depth, fbcon->bpp,
+ fbcon->pitch, NULL);
+ if (pixmap == NULL) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "Couldn't allocate pixmap fbcon contents\n");
+ return NULL;
+ }
+
+ intel_set_pixmap_bo(pixmap, bo);
+ drm_intel_bo_unreference(bo);
+out_free_fb:
+ drmModeFreeFB(fbcon);
+
+ return pixmap;
+}
+
+void intel_copy_fb(ScrnInfoPtr scrn)
+{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+ ScreenPtr pScreen = xf86ScrnToScreen(scrn);
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+ PixmapPtr src, dst;
+ unsigned int pitch = scrn->displayWidth * intel->cpp;
+ struct intel_crtc *intel_crtc;
+ int i;
+ int fbcon_id = 0;
+ for (i = 0; i < xf86_config->num_crtc; i++) {
+ intel_crtc = xf86_config->crtc[i]->driver_private;
+ if (intel_crtc->mode_crtc->buffer_id)
+ fbcon_id = intel_crtc->mode_crtc->buffer_id;
+ }
+ if (!fbcon_id)
+ goto fallback;
+
+ src = intel_create_pixmap_for_fbcon(scrn, fbcon_id);
+ if (src == NULL) {
+ xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+ "Couldn't create pixmap for fbcon\n");
+ return;
+ }
+
+ /* We dont have a screen Pixmap yet */
+ dst = GetScratchPixmapHeader(pScreen,
+scrn->virtualX, scrn->virtualY,
+scrn->depth, scrn->bitsPerPixel,
+pitch,
+NULL);
+ intel_set_pixmap_bo(dst, intel->front_buffer);
+
+ intel->uxa_driver->prepare_copy(src, dst, -1, -1, GXcopy, FB_ALLONES);
+
+ intel->uxa_driver->copy(dst, 0, 0, 0, 0,
+ scrn->virtualX, scrn->virtualY);
+
+
Re: Vertex buffers and the ring walker method
[ The xorg-driver-ati list would probably be better for this ] On Mon, 2012-06-11 at 18:09 -0700, Connor Behan wrote: > > I have finally found something that might explain why nothing is > drawn. A very old version of mesa has a comment "PCI cards use the > ring walker method, ie. the vertex buffer data is actually part of the > command stream." The card I've been testing on is AGP and the example > code I've been using was mainly tested on PCI. What is the alternative > to the ring walker method for AGP? I doubt there's any reason why the ring walker method wouldn't work with AGP. BTW, I assume you're always testing your code with direct rendering enabled, so the R128CCE* paths are hit. Because I don't see how the other Composite paths could work at all as they are. :) > == My flawed understanding of how it should work when WALK_RING is > supported == > > The only guidance I've been able to find, comes from r128_composite.c > in the kdrive ATI driver. Have you got that working BTW? > == What the problem is not == > > After hundreds of tries to use WALK_RING or work around it, I looked > at what would happen when I blindly copied pixels to the screen > instead. For composited text, the source picture is a black repeating > pixel. The information about the shape of the text is encoded in the > mask which has some parts transparent and some parts opaque. So I > turned my Composite hooks into Copy hooks and copied Mask to Dest. > Obviously this is stupid because the alpha channel would be taken > literally causing everything to get out of sync: > > argbargbargb > rgbrgbrgbrgb > > The text is therefore the wrong size and the wrong color and looks > horribly mangled. However, I think it's kinda neat how I can actually > make out what it says. This means that the pixmaps are in memory like > they're supposed to be and I haven't gotten the texture offsets wrong. Not for CPU access... For GPU acceess, the code pSrc->devPrivate.ptr - info->ExaDriver->memoryBase can't work, as devPrivate.ptr is normally NULL. You need to use exaGetPixmapOffset(). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ 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: [RFC PATCH:xf86-video-ati 9/15] Link with modules needed to build with no-undefined linking
On Mon, 2012-06-11 at 18:36 -0700, Alan Coopersmith wrote: > On 06/ 1/12 02:56 AM, Michel Dänzer wrote: > > On Fre, 2012-05-25 at 08:02 -0700, Alan Coopersmith wrote: > >> Signed-off-by: Alan Coopersmith > >> --- > >> src/Makefile.am | 13 +++-- > >> 1 file changed, 11 insertions(+), 2 deletions(-) > >> > >> diff --git a/src/Makefile.am b/src/Makefile.am > >> index dc77c02..4357135 100644 > >> --- a/src/Makefile.am > >> +++ b/src/Makefile.am > >> @@ -26,11 +26,12 @@ > >> # _ladir passes a dummy rpath to libtool so the thing will actually link > >> # TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing the .a, > >> etc. > >> > >> -radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) > >> +radeon_drv_la_LIBADD = $(LIBDRM_RADEON_LIBS) $(XORG_LIBS) -lpixman-1 -lm > > > > The driver doesn't depend on pixman directly, does it? I'd prefer that > > to be inherited from xserver somehow. If it isn't covered by -lfb > > anyway, that is. > > It does, thanks to the fb macros that now implement region operations using > pixman functions - nm on radeon_drv.so here shows it calling: > > pixman_region_copy > pixman_region_equal > pixman_region_subtract > pixman_region_union Ugh. I stand by my point though: This is an xserver implementation detail, so ideally the -lpixman-1 should be inherited from xserver. Maybe that's beyond the scope of this patch, but at the least the pixman link stanza needs to be determined via pkg-config. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ 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
