Displaying 20 results from an estimated 200 matches similar to: "[PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop"
2018 Feb 20
0
[PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
<ville.syrjala at linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> Replace the ad-hoc iturbt_709 property with the new standard
> COLOR_ENCODING property. Compiles, but not tested.
>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: nouveau at lists.freedesktop.org
> Cc: Ben
2013 Sep 08
1
[PATCH] drm/nv10/plane: add plane support for nv10-nv40
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a new "pvideo" engine -- that just seems way too
heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the
PVIDEO interrupts.
Even though
2013 Nov 15
4
[PATCH 1/5] drm/nv10/plane: fix format computation
Otherwise none of the format checks pass, since the width was still in
16.16 encoding.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
This must have been some sort of last-second cleanup I made and forgot to
test, because with this code, there's no way it could ever have worked...
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 17 +++++++++--------
1 file changed, 9
2017 May 20
3
[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes
This came out of some debugging I was doing to figure out how BE mode works
on this hardware. Among other things, it came out that we're not exposing
16-bpp mode support and that the ARGB8888 mode that we do expose is broken.
Also the overlay logic was pretty broken, I must have only tested with very
"normal" overlay buffer sizes with modetest before.
That said, this code has only
2017 Aug 06
4
[PATCH 0/4] Overlay / format improvements
This was all kicked off by me figuring out how the PPC byteswap thing worked.
In the end, we're keeping the implicit byteswap based on architecture, but also
expose the correctly supported formats, and fix some overlay details.
Overlay framebuffers have various funky requirements that should be enforced at
framebuffer creation time (these are set apart by their YUV formats). Further,
I
2017 May 20
4
[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes
This came out of some debugging I was doing to figure out how BE mode works
on this hardware. Among other things, it came out that we're not exposing
16-bpp mode support and that the ARGB8888 mode that we do expose is broken.
Also the overlay logic was pretty broken, I must have only tested with very
"normal" overlay buffer sizes with modetest before.
That said, this code has only
2020 Feb 06
5
[PATCH 0/4] drm/nouveau: Remove struct nouveau_framebuffer
All fields in struct nouveau_framebuffer appear to be obsolete. The
data structure can be replaced by struct drm_framebuffer entirely.
Patch 1 removes several unused fields from struct nouveau_framebuffer.
Patch 2 moves the field vma to struct nouveau_fbdev. The information
in vma is only relevant for fbdev emulation, and as such he field is
only used there.
Patch 3 removes nvbo from struct
2018 Feb 27
2
[PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> <ville.syrjala at linux.intel.com> wrote:
>> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2017 Aug 08
5
[PATCH libdrm] drm: Remove create_handle() drm_framebuffer "virtual".
Because all drivers currently use gem objects for framebuffer planes,
the virtual create_handle() is not required. This change adds a
struct drm_gem_object *gems[4] field to drm_framebuffer and removes
create_handle() function pointer from drm_framebuffer_funcs. The
corresponding *_create_handle() function is removed from each driver.
In many cases this change eliminates a struct *_framebuffer
2020 Feb 06
0
[PATCH 3/4] drm/nouveau: Remove field nvbo from struct nouveau_framebuffer
The buffer object stored in nvbo is also available GEM object in obj[0]
of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and
replace all references accordingly. This may require an additional cast.
With this change we can already replace nouveau_user_framebuffer_destroy()
and nouveau_user_framebuffer_create_handle() with generic GEM helpers.
Calls to nouveau_framebuffer_new()
2018 Feb 27
0
[PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> > <ville.syrjala at linux.intel.com> wrote:
> >> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>
> >> Replace the ad-hoc iturbt_709
2015 Jan 05
2
drm/nouveau: dont switch vt on suspend
Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com>
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3ed12a8cfc91..a4a586807903 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
ret = -ENOMEM;
goto
2016 Aug 22
10
[PATCH v2] drm/nouveau: add a LED driver for the NVIDIA logo
We received a donation of a Titan which has this useless feature
allowing users to control the brightness of the LED behind the
logo of NVIDIA. In the true spirit of open source, let's expose
that to the users of very expensive cards!
This patch hooks up this LED/PWM to the LED subsystem which allows
blinking it in sync with cpu/disk/network/whatever activity (heartbeat
is quite nice!). Users
2016 Aug 23
1
[PATCH v2] drm/nouveau: add a LED driver for the NVIDIA logo
On 23/08/16 11:31, Karol Herbst wrote:
> maybe it makes sense to expose the SLI LED, too.
>
> Regardless of my comments this patch is reviewed-by me.
You reviewed the wrong patch, I should have named the re-send v3.
I accidentally sent the v1 patch as a v2 :s
>
> 2016-08-23 1:39 GMT+02:00 Martin Peres <martin.peres at free.fr>:
>> We received a donation of a Titan
2010 Oct 26
22
[Bug 31122] New: Cannot control backlight intensity on Powerbook
https://bugs.freedesktop.org/show_bug.cgi?id=31122
Summary: Cannot control backlight intensity on Powerbook
Product: xorg
Version: unspecified
Platform: PowerPC
OS/Version: Linux (All)
Status: NEW
Severity: enhancement
Priority: medium
Component: Driver/nouveau
AssignedTo: nouveau at
2018 Aug 29
5
[PATCH v2 0/5] drm/nouveau: Backlight fixes and cleanup
Next version of https://patchwork.freedesktop.org/series/48596/ . Made
some important changes to the refactoring patch, but everything else is
the same.
Lyude Paul (5):
drm/nouveau: Check backlight IDs are >= 0, not > 0
drm/nouveau: Move backlight device into nouveau_connector
drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/
drm/nouveau: Cleanup indenting in
2018 Aug 23
6
[PATCH 0/5] drm/nouveau: Backlight fixes and cleanup
This series fixes some issues with nouveau's backlight support that were
causing kernel panics on module reloads, specifically on systems with
nouveau handling the backlight of one of the displays.
While we're at it, let's cleanup nouveau_backlight.c as well
Lyude Paul (5):
drm/nouveau: Check backlight IDs are >= 0, not > 0
drm/nouveau: Move backlight device into
2018 Aug 29
5
[PATCH v3 0/5] drm/nouveau: Backlight fixes and cleanup
Next version of https://patchwork.freedesktop.org/series/48596/ . Added
NV_INFO_ONCE and made "Move backlight device into nouveau_connector" use
that instead so we don't print the GMUX warning more then once.
Lyude Paul (5):
drm/nouveau: Add NV_PRINTK_ONCE and variants
drm/nouveau: Move backlight device into nouveau_connector
drm/nouveau: