[ Resending to the right mailing list. I looked up in MAINTAINERS, but
forgot to run "git bisect reset" and got the wrong address for
dri-devel@. Apologies to all who receive this twice. ]
After upgrading to 2.6.35-rc5, I noticed that my monitor reports a
refresh rate of 60 Hz when nouveau.ko is loaded, rather than the 75 Hz I
got on 2.6.34. Graphics card is an NV86 (GeForce 8500 GT), the monitor
is a 1280x1024 TFT (Yakumo 19AL) connected via VGA.
I bisected this to the following …
[View More]commit:
--8<---------------cut here---------------start------------->8---
commit c867df7043b738da4f4d358d7039c243a29b4272
Author: Adam Jackson <ajax(a)redhat.com>
Date: Mon Mar 29 21:43:21 2010 +0000
drm/edid: Reshuffle mode list construction to closer match the spec
Also, document what the spec says to do.
Signed-off-by: Adam Jackson <ajax(a)redhat.com>
Signed-off-by: Dave Airlie <airlied(a)redhat.com>
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9c4717f..858fedc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1377,10 +1377,24 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
quirks = edid_get_quirks(edid);
- num_modes += add_established_modes(connector, edid);
- num_modes += add_standard_modes(connector, edid);
+ /*
+ * EDID spec says modes should be preferred in this order:
+ * - preferred detailed mode
+ * - other detailed modes from base block
+ * - detailed modes from extension blocks
+ * - CVT 3-byte code modes
+ * - standard timing codes
+ * - established timing codes
+ * - modes inferred from GTF or CVT range information
+ *
+ * We don't quite implement this yet, but we're close.
+ *
+ * XXX order for additional mode types in extension blocks?
+ */
num_modes += add_detailed_info(connector, edid, quirks);
num_modes += add_detailed_info_eedid(connector, edid, quirks);
+ num_modes += add_standard_modes(connector, edid);
+ num_modes += add_established_modes(connector, edid);
if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
--8<---------------cut here---------------end--------------->8---
How do I get the 75 Hz refresh rate back? Adding "video=1280x1024@75"
as described in the nouveau wiki¹ has no effect.
Regards,
Sven
¹ http://nouveau.freedesktop.org/wiki/KernelModeSetting
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=29047
Summary: [r300g] Unknown opcode DDX with RV350
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: rankincj(a)googlemail.com
Output from piglit's glsl-derivs program:
r300 FP: Compiler …
[View More]Error:
r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown
opcode DDX
Using a dummy shader instead.
If there's an 'unknown opcode' message, please file a bug report and attach
this log.
Probe at (205,125)
Expected: 0.800000 0.400000 0.000000
Observed: 0.000000 0.000000 0.000000
And similarly for glsl-deriv-varyings.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
[ Let's try this again... ]
Ok, so the flink_to discussion rat-holed a bit on the binary blob
attachment issue. But before we even get to that, there are a lot of
issues that I'd some feedback on as well. There were a few bugs in
the patch that I've fixed, but I don't see the point in sending it out
again just yet, as I'd like to see if we can agree on some of the
higher level issues.
First of, I'm hoping we can get this ready for the next merge window.
The patch is written and I've tested …
[View More]it here with a libdrm test case
and am currently finishing the EGL support for this. One change I
might want to do is to add a blob type argument to the ioctls so
userspace has a standardized way of indication what the format of the
data is (what Keith pointed out). That's a fairly simple change and
the patch itself is simple enough to begin with, so I don't expect a
lot of tricky issues with the implementation.
Along with the flink_to ioctl, I'm proposing that we drop the DRM_AUTH
requirement for accessing the gem ioctls. Specifically, for intel,
I'm suggesting that we drop the DRM_AUTH requirement on
DRM_IOCTL_GEM_FLINK,
DRM_IOCTL_GEM_OPEN,
DRM_I915_GEM_EXECBUFFER,
DRM_I915_GEM_EXECBUFFER2,
DRM_I915_GEM_BUSY,
DRM_I915_GEM_THROTTLE,
DRM_I915_GEM_CREATE,
DRM_I915_GEM_PREAD,
DRM_I915_GEM_PWRITE,
DRM_I915_GEM_MMAP,
DRM_I915_GEM_MMAP_GTT,
DRM_I915_GEM_SET_DOMAIN,
DRM_I915_GEM_SW_FINISH,
DRM_I915_GEM_SET_TILING,
DRM_I915_GEM_GET_TILING,
DRM_I915_GEM_GET_APERTURE,
DRM_I915_GEM_MADVISE,
which should allow clients to create buffers, submit rendering against
them and share them with a priviledged (in the sense that it controls
scanout) display server. Access to these ioctls will then only be
guarded by the permissions on /dev/dri/cardX, which all distros
restrict to the 'local' user (that is, excluding ssh and similar) in
one way or another. How do we feel about that? Maybe it's something
the master needs to request, so that only X servers that use flink_to
will activate this mode?
flink_to doesn't in itself solve the security problem, since user
space can still submit a batch buffer that reads or writes to an
absolute gtt offset (that is, no relocation). The X front buffer
location is typically pretty predictable, for example. flink_to does
give us the infrastructure to implement a secure system though. There
are several ways this could be done: use a sw command checker to
reject absolute gtt offsets, unbind buffers from all other clients
before running executing the commands or use per-process gtt or
similar hw support.
Then there's the data passing mechanism part of flink_to. I'm
suggesting that we allow applications to attach a blob to an flink_to
name, which will be passed to the process calling open_with_data on
the name. The format of the blob is defined by userspace, typically
libdrm or mesa, and lets us marshal meta data about the buffer along
with granting access to the buffer. And just to be clear, the kernel
has no need for this meta data, it doesn't even understand the format.
But it will make protocoles and user level APIs simpler, and it's not
going to be a resource drain in the kernel. There's a 2k max size on
the attached data, and a buffer can only have one flink_to name
pending per file_priv. I didn't see any strong objections in the
thread, but I understand the concerns. We're debating a minimal
kernel API with a kludgey userspace vs kernel API with convenience
features and much simpler userspace.
Anyway, I'll post an update when I get a working userspace on top of
this proposal. In the meantime I would much appreciate feedback on
the above issues.
Kristian
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=29023
Summary: [r300g] Stellarium screen is black
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/DRI/r300
AssignedTo: dri-devel(a)lists.freedesktop.org
ReportedBy: jlp.bugs(a)gmail.com
After a recent update of mesa from git Stellarium screen stays …
[View More]black, even if
you drag the sky around. You can only make it draw something if you move the
mouse to the left or bottom part of the screen where the slide in menus are.
I've bisected the commits and the one causing the problem is:
78e8a8765f435bf0902d62afbcb3b8d68a0b716f
r300g: clear and copy a resource with a rectangular point sprite
This is on HP Compaq nx6325 laptop with RS482 based integrated graphics card.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
So here is something i have been thinking on for a while and never
get around to actually code it until recently. I needed|wanted it
as i was working on improved GPU reset. Issue i faced is that despite
trying hard to make clean code reusable btw asic we ended up with some
messy code path (especially in error path) and you basicly have to
write for each asic a special function handling initialization+
finalization add 2 other for suspend/resume and finaly add one for
reset and one for power …
[View More]management.
So the idea of unit is to give each unit a set of function :
init,fini,suspend,resume,hold,unhold
Unit are things like : CP, MC, MemoryManager, GEM, CLK, ...
Now instead of writing one init/fini/suspend/resume function
you just provide for each asic the following :
struct radeon_unit_funcs *r100_units[] = {
»······&r100_unit_errata,
»······&r100_unit_vga,
»······&r100_unit_common,
»······&radeon_unit_scratch,
»······&radeon_unit_sr,
»······&radeon_unit_surface,
»······&radeon_unit_reset,
»······&radeon_unit_bios,
»······&r100_unit_clock,
»······&r100_unit_mc,
»······&radeon_unit_fence,
»······&radeon_unit_irq,
»······&radeon_unit_mm,
»······&radeon_unit_agp,
»······&r100_unit_gart,
»······&r100_unit_irq,
»······&radeon_unit_gem,
»······&r100_unit_cs,
»······&r100_unit_cp,
»······&r100_unit_ib,
»······NULL
};
and a common helper function just go through the list
and init each unit, for fini it goes in reverse order.
resume/suspend are like init/fini, suspend goes in
reverse order while resume goes in normal order
radeon_unit_sr is a fake helper unit just to know
from which point you start/end suspend/resume,
same for radeon_unit_reset
So with that approach i think it's lot easier to
figure out dependency btw unit and in which order
things get call.
I think it will help to untangle some of the code
path that are tricky today to follow. Thought there
is a downside any change like this is likely to
introduce regression and i hate those like others,
anyway i think the longterm benefit are greater than
the temporary disturbance we can even have the unit
path coexist with current code and allow it to
stabilize on its own before switching over and
removing old path.
So before i go any further what is your opinion
on this ? Attached is a patch which shows the
approach for r100/r200 asic (tested and it
works) as you can see it can be done without
touching the old path and we can also add an
option to select btw old/new path.
Cheers,
Jerome
[View Less]