[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #23 from SMF smf.li...@ntlworld.com --- (In reply to SMF from comment #21) Using cpu-z on windows the graphics tab shows the Intel device as having 4GB and the Nvidia devices is reported as 1GB. The literature that came with the laptop suggests that the VRAM is 4 GB (NVIDIA GT840M 4 GB) so I think the answer is YES. My orginal hesitation stems from the fact that the intel drm is reporting 2GB: [0.669881] Linux agpgart interface v0.103 [0.669993] [drm] Initialized drm 1.1.0 20060810 [0.670484] [drm] Memory usable by graphics device = 2048M [0.670569] [drm] Replacing VGA console driver [0.671121] Console: switching to colour dummy device 80x25 [0.689829] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). That may be a miscalculion/limitation for this system. Could this be a consequence of this systems Intel/Nvidia hybrid setup? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89558] [NV118] GM108 not supported by nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=89558 --- Comment #24 from SMF smf.li...@ntlworld.com --- (In reply to SMF from comment #23) (In reply to SMF from comment #21) Using cpu-z on windows the graphics tab shows the Intel device as having 4GB and the Nvidia devices is reported as 1GB. The literature that came with the laptop suggests that the VRAM is 4 GB (NVIDIA GT840M 4 GB) so I think the answer is YES. My orginal hesitation stems from the fact that the intel drm is reporting 2GB: [0.669881] Linux agpgart interface v0.103 [0.669993] [drm] Initialized drm 1.1.0 20060810 [0.670484] [drm] Memory usable by graphics device = 2048M [0.670569] [drm] Replacing VGA console driver [0.671121] Console: switching to colour dummy device 80x25 [0.689829] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). That may be a miscalculion/limitation for this system. Could this be a consequence of this systems Intel/Nvidia hybrid setup? Does the fact that my kernel and os are built for 32bit pae limit the drm vram to less than that physically present i.e. limited to 2G in this case? -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #10 from poma pomidorabelis...@gmail.com --- Created attachment 114602 -- https://bugs.freedesktop.org/attachment.cgi?id=114602action=edit NV50 log Whatever is actually happening here is not evident in the logs: dmesg, Xorg.*.log, lightdm.log(DEBUG) and x-*-greeter.log(DEBUG). However, here we go. As Ilia concluded, EXA is a puzzle here. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #9 from poma pomidorabelis...@gmail.com --- (In reply to andrew p. from comment #7) Some clarifications: - Greeter is usual GTK3 application. - No WM or compositor run in greeter session. - Greeter creates one GtkWindow for each monitor. - Greeter uses standard cairo functions to draw monitor's window background. There are no login or panel windows - just child widgets inside fullscreen window. This grey color looks like default window color - just set background=#default to see it. So, the question - why gtk draw semi-transparent panel correctly (using parent window background as base) and do not do it for free space. Add allow-debugging=true option to lightdm-gtk-greeter.conf to get more informative log. Some questions: 1. What happened if background is color (#0f0)? I don't expect that there will be any difference, just interesting. 2. Another gtk theme? Or empty theme-name=. Color codes work OK, theme also does not affect the final outcome. background color (#0f0) - green, works OK as any other. I saw very similar bug some time ago - laptop with archlinux and catalyst. In some cases gtk didn't draw whole windows except some widgets (text entries - blinking cursor). But this bug is gone now. Thanks for answering. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #7 from andrew p. pan.pav@gmail.com --- Some clarifications: - Greeter is usual GTK3 application. - No WM or compositor run in greeter session. - Greeter creates one GtkWindow for each monitor. - Greeter uses standard cairo functions to draw monitor's window background. There are no login or panel windows - just child widgets inside fullscreen window. This grey color looks like default window color - just set background=#default to see it. So, the question - why gtk draw semi-transparent panel correctly (using parent window background as base) and do not do it for free space. Add allow-debugging=true option to lightdm-gtk-greeter.conf to get more informative log. Some questions: 1. What happened if background is color (#0f0)? I don't expect that there will be any difference, just interesting. 2. Another gtk theme? Or empty theme-name=. I saw very similar bug some time ago - laptop with archlinux and catalyst. In some cases gtk didn't draw whole windows except some widgets (text entries - blinking cursor). But this bug is gone now. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89730] NV50: LightDM GTK+ Greeter Background - inconsistent display
https://bugs.freedesktop.org/show_bug.cgi?id=89730 --- Comment #8 from Ilia Mirkin imir...@alum.mit.edu --- Well, given that it works OK with glamor (and other hardware), this feels most likely to be a bug in the EXA implementation somewhere. There's a weird bug where if you do some crazy things you can get stale window contents... this doesn't feel like that one though. Could be a compositing or who knows what issue. In a *perfect* world, there would be a simple stand-alone app that reproduces this, and we can use that to debug. Not sure how feasible that is. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] header intact
___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
