related to X. And drm should be able to live without X. So why would
libdrm-intel rely on libpciaccess/X to be build? I'm sure we could do
without it, since all other drivers do.
As things are right now, would that imply using a X lib to build
libdrm-intel and then use it with Wayland for instance
fix in a hurry (lots of copy-paste), and maybe it would be better to
re-do it properly...
Thanks again,
Kirill
and actual brightness is maximum (255*2890=736950). I see no other
change after it until manual brightness change. This is a totally
reversed to your problem.
Could you help to get the LPBC value in the initial dark condition? If
it's not corresponds to 255, maybe something sneaks and changes it b
passing a framebuffer between two V4L2 devices and between a V4L2 device
and GPU. The V4L2 device can either be an input or an output one.
The original idea were to add yet-another-mmap-mode at the VIDIOC streaming
ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed
there, this
which contradicts with the topic we are discussed. Regardless of the
combination_mode, the log seems to work .. weird.
2011/5/9 Melchior FRANZ
> * Joey Lee -- Monday 09 May 2011:
> > The following is debug patch, and please add kernel parameter
> > drm.debug=0x02 :
>
> The result is with acpi_o
Linux Cg bug or Trine Linux version bug.
Windows Trine version (from humble bundle) with WINE works perfectly.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
logout is being done with libICE. I know it is not being done with Hal,
Consolekit or the XKillClient Xlib function. I will update this bug report as
soon as I know which function causes this and have a testcase ready. If you
think it will lead to a fix I would be willing to use a pencil and paper
The Xorg.0.log from the previous boot is attached.
Gabriel
--BOKacYhQ+x31HxR3
Content-Type: application/x-trash
Content-Disposition: attachment; filename="Xorg.0.log.old"
Content-Transfer-Encoding: quoted-printable
=0AX.Org X Server 1.7.7=0ARelease Date: 2010-05-04=0AX Protocol Version 1
[KMS] Kernel modesetting enabled.
[...]
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD RV770
00 [VGA controller])
(PCI-E)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
While screen is loading application will crash with following backtrace
~/Savage2/savage2.bin
warning: The VAD has been replaced by a hack pending a complete rewrite
EE r600_pipe.c:343 r600_get_param - r600: unknown param 45
EE r600_pipe.c:343 r600_get_param - r600: unknown param 45
*** glibc det
one seemed fine and the interface looked okay to me.
Dave.
backlight handling, and it would be sad if it wasn't fixed in 2.6.38.
But I think this is only because I have a gen 2 and the check for
combination mode for gen 2 was added in 2.6.37, everyone else already
had the buggy backlight behaviour for ages. Without the check gen 2
works correctly because t
Iwai
Date: Mon, 21 Feb 2011 14:19:27 +0100
Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode
The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870
drm/i915: Refactor panel backlight controls
causes a regression for GM45 that is using the combined mode for
controllin
When I load the fglrx ati proprietary driver (11.1) for the 5450 card, then=
I
get throughputs of about 2GB/s in both directions.=20
Running the same test in same environment on the HD5970=20
with the gallium drivers and kernel mode setting and pcie_gen2 activation, i
get about the same figures a
[12.618] (EE) open /dev/fb0: No such file or directory
[12.618] (EE) No devices detected.
[12.618]
Fatal server error:
[12.618] no screens found
[12.618]
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more
guest (but without PCI passthrough devices).
> On a 4GB machine or less, that would be the same as kernel memory.
> Now, if 4 guests think they can allocate 2GB of coherent memory
> each, you might run out of kernel memor
for this, it can also go to /dev/nirvana.
The version related informations for drm-core seems also not to be
lovely maintained.
How long do we see 1.1.0 as version? For ages?
Did you know about interface-version?
You found the places for DRM_IF_*?
No, this is not a riddle or quiz-show, just have
attached setup.log), which I partly cherry-picked [1] or refreshed
against linux-next (next-20101217).
They worked also with yesterdays next-20101221.
I have attached a follow-up/fix-up patch for one of Daniel's patchsets.
(See below
"danvet-drm-for-sedat-dilek-v2/0006-drm-nouveau-don-t-munge-in-d
would allow easy abuse of the GPU to access any system ram. There is a
reason we do expensive command checking in the other amd gpu driver
(drivers/gpu/drm/radeon/*cs.c files)
Cheers,
Jerome
mapping object in drm file and iirc we will report error if we can't
find a mapping for userspace object). I guess at one point we should
start thinking about what we want to do on that front.
Doing a v3.
Cheers,
Jerome
Hi Linus,
sorry this is a bit later than I expected got sidetracked into a real-life
gastro bug for a couple of days just after merge window opened,
Main features amongst it all:
new stub driver for poulsbo backlight support
drm core: kdb lut support, lots of cleanups, edid enhancement for audi
Hi Linus,
sorry this is a bit later than I expected got sidetracked into a real-life
gastro bug for a couple of days just after merge window opened,
Main features amongst it all:
new stub driver for poulsbo backlight support
drm core: kdb lut support, lots of cleanups, edid enhancement for audi
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
DIN: S-video?
Clearly your working monitor (DVI) is on output DVI-0.
What is the actual card you have? (manufacturer, model)
List all of the connectors that it actually (physically) has.
I can think of a few possibilities:
1) That the DVI and HDMI plugs are wired into the same place,
2) That the
test different graphical settings yet.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
bugs 13/15
fdo20701 fail
Returncode: 1
Errors:
Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010 06:16:40
Output:
init:104: framebuffer status = 0x8cdd
--
then
fdo25614-genmipmap fail
---
Returncode: 1
Errors:
Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010 06:16:40
(E17 init)
E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0
E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896
(output blinking starts)
E17 INIT: XINERAMA SCREEN: [0], 1280x1024+0+0
E17 INIT: XINERAMA CHOSEN: [153045780], 0x153045764+0+153046580
(e17 crash, try to recover)
E17 INIT: XINERAMA
shouldn't be firing at all under normal circumstances. (Looking at it we
don't handle the introduction of the BSD ring correctly, but that is
irrelevant on the EeePC 900.)
Do the stalls and tearing go away with:
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index
Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work(). The former returns 0 on success and -errno on
failures while the latter never fails
start of the GPU reset, which is the last callsite to unlock cp.mutex,
ie radeon_gpu_reset->radeon_resume->rv770_resume->rv770=
_startup->r600_cp_resume->radeon_ring_test->r600_ring_test->radeon_ring_unl=
ock_commit>
before the hang at
radeon_gpu_reset->->drm_helper_resume_force_mode->drm_c=
rtc_he
radeontool patched with attachement 34810
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
df16dd53c575d0cb9dbee20a3149927c862a9ff6 hwmon: (ltc4245) Read only one GPIO
pin
and *sometime* before this commit:
09bdf591f4724c7d0328d4d7b8808492addb5a28 drm/radeon/kms: fix dpms state on
resume
Alex, I am pretty much a 'newb' when it comes to git and the kernel in general
and currently git
/* A typical clean-up sequence for objects stored in an idr tree, will
* use idr_for_each() to free all objects, if necessary, then
* idr_remove_all() to remove all ids, and idr_destroy() to free
* up the cached idr_layers.
*/
We were missing the vital idr_rmove_all() step and so were leaking
crappy monitors are still crappy. The hw i2c engines are mostly there
to reduce CPU usage and allow i2c transactions to be interrupt driven.
Alex
than hw can handle, but it seems to use only a small portion of the buffer.
I've changed the code so that it does not abort"
Since the game was working fine with this hardware in Windows (and my RV530 is
well above minimum requirements) I suspected this to be a Wine issue and I
asked at their forum
itdiff;h=3Df892034a8ce80ed7098f667aae2eb6300e570603
is part of vanilla 2.6.35-rc4 and -rc5, but neither kernel works for
me.
> Does this patch help?
(0001-drm-radeon-kms-fix-possible-mis-detection-of-sidepor.patch)
After adding this to 2.6.35-rc5 the system boots and works so far.
But the CP is
If I go one commit back, cubestorm works. It's quite a large commit and it's
not clear to me what the commit does in terms of functionality.
BTW, cubestorm is a single-buffered application.
--=20
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
--- You are receiving t
a) Both r300c and r300g have difficulty with compressed textures, and
b) r300g also has a more serious problem with b8g8r8a8_unorm, b4g4r4a4_unorm,
b5g6r5_unorm textures (and possibly others), because these are what WoW uses
when compressed texture support isn't available.
--
Configure bugmail: h
--=20
controlled by gamma light
radeon_test_moves
(radeon_ttm_backend_bind called through callback function)
- radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind
- radeon_gart.c:radeon_gart_bind calls pci_map_page
- pci_map_page is alpha_pci_map_page, which calls...
- alpha_pci_map_page calls pci_iommu.c:pci_m
mesa upgrade to f4bcd0ca some hours later. At the time I installed lugaru (and
did not see any crash) I had just installed 2.6.34-996.201005261005 (drm-next
from mainline kernel PPA). Hours before I had installed 2.6.34-999.201005231006
(linus tree). So I must have been running one of those kernels
0x46c266f0 0x46c42578 Yes (*) /usr/lib/libpng12.so.0
0x47c162d0 0x47c306b8 Yes (*) /usr/lib/libjpeg.so.62
0x46da7740 0x46db14b8 Yes (*) /usr/lib/libXi.so.6
0x46aea720 0x46af4ff8 Yes (*) /usr/lib/libXext.so.6
0x4686a620 0x468758e8 Yes (*) /lib/libz.so.1
0x4a84fe00 0x4a
Client side is other machine: indirect glx -> via network.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
versions of libdrm from 2.4.18 on. I suppose this means that the Arch Linux
people must have patched their version of Linux kernel 2.6.33.3, otherwise it
should not have worked with that version of libdrm? Finally, there is the
xf86-video-nouveau package, which now is version 0.0.15_git20100314-1
started with the kernel configuration for Arch Linux, but ended up removing
many modules as otherwise that 350 MHz Pentium II needed 6 hours to compile. I
updated the system before I tried the patch. These are the current versions
for Arch Linux:
nouveau-drm 0.0.16_20100313-2
xf86-video-nouveau
invaluable for delving into and fixing some obnoxious driver bugs. I
suspect its honeymoon period is now over - those bugs that it could
detect easily have been fixed (I hope). In order to capture the relevant
information for later chipset generations, we will need to parse the
command stream and i
"r300: Max size of the constant buffer is 256*4 floats."
immediately followed by abort in the code.
We really need fine-grained shader limits, applications seem to make fatal
decisions based on them.
--=20
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=3Demail
--- You are
101 - 150 of 150 matches
Mail list logo
