Hi!
> > (Hint: it is LEDs below regular keyboard.)
>
> Yes, I know, and if you read this email and the few others, you'll read
> that I own a few of them already (for a long time), and I worked on a
> cross vendor userspace API to configure them. So I know what I am
> talking about.
Ok.
> > > T
On Wed 2024-10-02 13:01:05, Ilpo Järvinen wrote:
> On Wed, 2 Oct 2024, Pavel Machek wrote:
>
> > Hi!
> >
> > > > +static struct wmi_driver tuxedo_nb04_wmi_ab_driver = {
> > > > + .driver = {
> > > > + .name = &qu
Hi!
> > +static struct wmi_driver tuxedo_nb04_wmi_ab_driver = {
> > + .driver = {
> > + .name = "tuxedo_nb04_wmi_ab",
> > + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > + },
> > + .id_table = tuxedo_nb04_wmi_ab_device_ids,
> > + .probe = probe,
> > + .remove = remove,
On Wed 2024-10-02 10:13:10, Benjamin Tissoires wrote:
> On Oct 01 2024, Pavel Machek wrote:
> > Hi!
> >
> > > PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
> > > all of the requirements here:
> > > - need to be dynamic
> >
Hi!
> PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
> all of the requirements here:
> - need to be dynamic
> - still unsure of the userspace implementation, meaning that userspace
> might do something wrong, which might require kernel changes
> - possibility to extend l
, HID_REQ_SET_REPORT);
printk("raw: %d, einval %d, eagain %d\n", i, -EINVAL, -EAGAIN);
msleep(100);
return 0;
}
#define SIZE 128
const int real_size = SIZE;
static ssize_t hx_sysfs_read(struct file *fp, struct kobject *kobj,
struct bin_attribute * b,
char *buf, lo
Hi!
> The TUXEDO Sirius 16 Gen1 and TUXEDO Sirius 16 Gen2 devices have a per-key
> controllable RGB keyboard backlight. The firmware API for it is implemented
> via WMI.
Ok.
> To make the backlight userspace configurable this driver emulates a
> LampArray HID device and translates the input from
On Fri 2024-09-27 18:08:52, Benjamin Tissoires wrote:
> On Sep 26 2024, Werner Sembach wrote:
> > Hi,
> > took some time but now a first working draft of the suggested new way of
> > handling per-key RGB keyboard backlights is finished. See:
> > https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-6
Hi!
> [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ]
>
> Check the fb_channel_number range to avoid the array out-of-bounds
> read error
We can still have array out-of-bounds, right? As soon as that function
returns 0x8000 .
drivers/gpu/drm/amd/amdgpu/amdgpu_df.h: u32 (*get_fb
Hi!
> From: Jesse Zhang
>
> [ Upstream commit c8c19ebf7c0b202a6a2d37a52ca112432723db5f ]
>
> Avoid using the negative values
> for clk_idex as an index into an array pptable->DpmDescriptor.
>
> V2: fix clk_index return check (Tim Huang)
> dpm_desc = &pptable->DpmDescriptor[clk_index];
>
Hi!
> From: Tim Huang
>
> [ Upstream commit 9a5f15d2a29d06ce5bd50919da7221cda92afb69 ]
>
> Clear warning that uses uninitialized value fw_size.
This is queued for 5.15 and 6.10, but not 6.1, for example. Mistake?
Best regards,
Pa
Hi!
> > IMO working with the HID LampArray is the way forward. So I would
> > suggest to convert any non-HID RGB "LED display" that we are talking
> > about as a HID LampArray device through `hid_allocate_device()` in the
> > kernel. Basically what you are suggesting Hans. It's just that you don't
pecials(hdev);
hid_hw_stop(hdev);
}
static const struct hid_device_id hx_devices[] = {
{ HID_USB_DEVICE(0x0951, 0x16be) },
{ }
};
MODULE_DEVICE_TABLE(hid, hx_devices);
static struct hid_driver hx_driver = {
.name = "hx",
.id_table = hx_devices
Hi!
> > Ok, so machine is ready to be thrown out of window, again. Trying to
> > play 29C3 video should not make machine completely unusable ... as in
> > keyboard looses keystrokes in terminal.
>
> Well, that at least sounds like you can bisect it with a very clear test-case?
>
> Even if you do
Hi!
> > > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > > this sound familiar? Pavel says things have gotten much slower in
> > > 6.10: "something was very wrong with the performance, likely to do
> > > with graphics"
> >
> > Actually, maybe it's not graphics at all. R
Hi!
> [WHY]
> PSP can access DCN registers during command submission and we need
> to ensure that DCN is not in PG before doing so.
>
> [HOW]
> Add a callback to DM to lock and notify DC for idle optimization exit.
> It can't be DC directly because of a potential race condition with the
> link pr
Hi!
> [ Upstream commit a0cf36546cc24ae1c95d72253c7795d4d2fc77aa ]
>
> The pointer parent may be NULLed by the function amdgpu_vm_pt_parent.
> To make the code more robust, check the pointer parent.
If this can happen, it should not WARN().
If this can not happen, we don't need the patch in sta
Hi!
> > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > this sound familiar? Pavel says things have gotten much slower in
> > 6.10: "something was very wrong with the performance, likely to do
> > with graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
Hi!
> > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > this sound familiar? Pavel says things have gotten much slower in
> > 6.10: "something was very wrong with the performance, likely to do
> > with graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
Hi!
> > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > this sound familiar? Pavel says things have gotten much slower in
> > 6.10: "something was very wrong with the performance, likely to do
> > with graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
On Sun 2024-05-26 22:44:35, Jason-JH.Lin wrote:
> From: Jason-jh Lin
>
> For the Secure Video Path (SVP) feature, inculding the memory stored
> secure video content, the registers of display HW pipeline and the
> HW configure operations are required to execute in the secure world.
This feature g
Hi!
> For all these reasons the display analogy really is a bit fit for these
> keyboards
> we tried to come up with a universal coordinate system for these at the
> beginning
> of the thread and we failed ...
I quite liked the coordinate system proposal. I can propose this:
Vendor maps the ke
Hi!
> > To be honest, I think the kernel shouldn't include too much high-level
> > complexity. If there is a desire to implement a generic display device on
> > top of the RGB device, this should be a configurable service running in
> > user space. The kernel should provide an interface to expo
Hi!
> > > so after more feedback from the OpenRGB maintainers I came up with an even
> > > more generic proposal:
> > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >
> > > >evaluate-set-command ioctl taking:
> > > >{
> > > > enum command /* one o
Hi!
> > Yeah, so ... this is not a interface. This is a backdoor to pass
> > arbitrary data. That's not going to fly.
>
> Pavel, Note the data will be interpreted by a kernel driver and
> not passed directly to the hw.
Yes, still not flying :-).
> With that said I tend to agree that this seems
Hi!
> so after more feedback from the OpenRGB maintainers I came up with an even
> more generic proposal:
> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >evaluate-set-command ioctl taking:
> >{
> > enum command /* one of supported_commands */
> >
Hi!
> > And while I would personally hate it, you can imagine a use case where
> > you'd like a keypress to have a visual effect around the key you
> > pressed. A kind of force feedback, if you will. I don't actually know,
> > and correct me if I'm wrong, but feels like implementing that outside o
Hi!
> > > And then storing RGB in separate bytes, so userspace will then
> > > always send a buffer of 192 bytes per line (64x3) x 14 rows
> > > = 3072 bytes. With the kernel driver ignoring parts of
> > > the buffer where there are no actual keys.
> > That's really really weird interface. If you
Hi!
> >> 2. Implement per-key keyboards as auxdisplay
> >>
> >> - Pro:
> >>
> >> - Already has a concept for led positions
> >>
> >> - Is conceptually closer to "multiple leds forming a singular
> >> entity"
> >>
> >> - Con:
> >>
> >> - No preexisting UPower suppor
Hi!
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here
> for a potential userspace driver implementation ...
>
> So a quick summary for the ideas floating in this thread so far:
>
> 1. Expand le
Hi!
> > > From: Ziqi Zhao
> > >
> > > [ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
> > >
> > > The connector_set contains uninitialized values when allocated with
> > > kmalloc_array. However, in the "out" branch, the logic assumes that any
> > > element in connector_set would b
On Mon 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula
> wrote:
> >
> > One could also reasonably make the argument that controlling the
> > individual keyboard key backlights should be part of the input
> > subsystem. It's not a display per se. (Unless you
Hi!
> >> So... a bit of rationale. The keyboard does not really fit into the
> >> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> >> a matrix of them.
> >
> > Makes sense.
> >
> >> We do see various strange displays these days -- they commonly have
> >> rounded corners and
Hi!
> > > From: Alex Deucher
> > >
> > > [ Upstream commit 49afe91370b86566857a3c2c39612cf098110885 ]
> > >
> > > For pptable structs that use flexible array sizes, use flexible arrays.
> > >
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
> > > Reviewed-by: Mario Limo
Hi!
> This patchset adds three secure heaps:
> 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
>The buffer is reserved for the secure world after bootup and it is used
>for vcodec's ES/working buffer;
> 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This
Hi!
> > An orthogonal issue is labeling all of those regions. I think we should
> > start with fully obscured areas and maybe less readable ones like the
> > waterfall edges. Still, different features should live on different
> > masks – even if we don't attach meaningfull labels (like 'notch' or
Hi!
> coming from the leds mailing list I'm writing with Pavel how to best handle
> per-key RGB keyboards.
>
> His suggestion was that it could be implemented as an aux display, but he
> also suggested that I ask first if this fits.
Thanks for doing this.
> The specific keyboard RGB controller
Hi!
> > The specific keyboard RGB controller I want to implement takes 6*21 rgb
> > values. However not every one is actually mapped to a physical key. e.g. the
> > bottom row needs less entries because of the space bar. Additionally the
> > keys are ofc not in a straight line from top to bottom.
Hi!
> From: AngeloGioacchino Del Regno
>
> [ Upstream commit fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f ]
>
> Change logging from drm_{err,info}() to dev_{err,info}() in functions
> mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
> essential to avoid getting NULL pointer kernel p
Hi!
> From: hackyzh002
>
> [ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]
>
> The type of size is unsigned, if size is 0x4000, there will be an
> integer overflow, size will be zero after size *= sizeof(uint32_t),
> will cause uninitialized memory to be referenced later
I onl
Hi!
> From: Helge Deller
>
> [ Upstream commit 5cf9a090a39c97f4506b7b53739d469b1c05a7e9 ]
>
> Add missing cleanups in error path.
If we insist this is important enough for -stable, it will need
tweaking. The function returns void, so we can't return a value.
Best regards,
Hi!
> > Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
> >> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
> >> driver.
> >
>
...
> I fixed that before applying, also removed the "are" in the sentence
> above, since it sounded off and repharsed subject line as "Fix typos
>
On Wed 2023-03-22 10:05:13, Rodrigo Siqueira wrote:
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Some changelog would be useful.
> +++ b/include/drm/display/drm_dp.h
> @@ -977,6 +977,8 @@
> # define DP_EDP_BACKLIGHT_FR
Hi!
> > +config LEDS_AW200XX
> > + tristate "LED support for Awinic AW20036/AW20054/AW20072"
> > + depends on LEDS_CLASS
> > + depends on I2C
> > + help
> > + This option enables support for the AW20036/AW20054/AW20072 LED
> > driver.
> > + It is a 3x12/6x9/6x12 matrix LED driver
Hi!
> This series add support for the display present in the PinePhone Pro.
>
> Patch #1 adds a driver for panels using the Himax HX8394 panel controller,
> such as the HSD060BHW4 720x1440 TFT LCD panel present in the PinePhone Pro.
>
> Patch #2 adds a devicetree binding schema for this driver a
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At leas
r now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
>
> Signed-off-by: Uwe Kleine-König
LED part:
Acked-by: Pavel Machek
Best regards,
Pavel
> sta
Hi!
> > I used to be able to do:
> >
> > pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
> > warning: output HDMI1 not found; ignoring
> > pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
> > warning: output VGA1 not found; ignoring
> >
> > ...but now I have
Hi!
I used to be able to do:
pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
warning: output HDMI1 not found; ignoring
pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
warning: output VGA1 not found; ignoring
...but now I have to do:
pavel@duo:~$ xrandr
Hi!
> From: Alyssa Rosenzweig
>
> [ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
>
> Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
> from kbase. kbase lists this workaround as used on Mali-G57.
AFAICT this quirk is not used anywhere in 5.10, and its users
Hi!
In this series, I only received patches up-to 42/46. Is problem at sender or
receiver?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/
Hi!
> From: Alice Chen
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
> LED current sources, a RGB LED driver, a backlight WLED drive
Hi!
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED dr
On Fri 2022-07-22 18:23:58, ChiaEn Wu wrote:
> From: Alice Chen
>
> Add MediaTek MT6370 flashlight binding documentation.
>
> Signed-off-by: Alice Chen
> Reviewed-by: Krzysztof Kozlowski
You'll need to get sign-offs right... And review from dt people before
this can be applied.
Best regards,
This
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
Hi!
> Going forward, I'll be using my kernel.org for upstream work.
>
Acked-by: Pavel Machek
Let me know if you want to take it through the LED tree.
Best regards,
Pavel
--
People of Russia, stop Putin before his war
Hi!
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias dri
Hi!
> [ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
>
> clk_put() already checks the clk ptr using !clk and IS_ERR()
> so there is no need to check it again before calling it.
Nice cleanup, but not a bugfix; we don't need it in -stable.
Best regards,
Hi!
> From: Xiang wangx
>
> [ Upstream commit fc378794a2f7a19cf26010dc33b89ba608d4c70f ]
>
> Delete the redundant word 'its'.
Calling typo in comment "syntax error" is ... interesting. Anyway, we
don't need this in stable.
Best regards,
Hi!
> From: Maxime Ripard
>
> [ Upstream commit 2523e9dcc3be91bf9fdc0d1e542557ca00bbef42 ]
>
> We'll need to extend the vc4_async_flip_state structure to rely on
> another callback implementation, so let's move the current one into a
> union.
This and [04/22] drm/vc4: crtc: Use an union to sto
On Mon 2022-05-09 12:43:00, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 RDMA definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
Your signoff will be needed, too.
Best regards,
Pavel
Hi!
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except fo
e not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
Acked-by: Pavel Machek
Hi!
This series is truncated .. I only got first patches. Similary, 5.10
series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add
checking to s5p_mfc_probe... is last one I got.
I got all the patches before that, so I believe it is not problem on
my side, but I'd not mind someone con
Hi!
> From: Xie Yongji
>
> [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
>
> The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
> or virtio_gpu_init() failed. In this case, we should avoid the cleanup
> in virtio_gpu_release().
The check is in wrong place at l
Hi!
> > Revert "drm/radeon: Fix reference count leaks caused by
> > pm_runtime_get_sync"
> > Revert "drm/radeon: fix multiple reference count leak"
> > Revert "drm/amdkfd: Fix reference count leaks."
>
> I didn't review these carefully, but from a quick look they all seem
> rather incon
On Wed 2021-03-10 13:56:29, Peiyong Lin wrote:
> On Mon, Dec 21, 2020 at 12:10 PM Peiyong Lin wrote:
> >
> > Historically there is no common trace event for GPU frequency, in
> > downstream Android each different hardware vendor implements their own
> > way to expose GPU frequency, for example as
Hi!
> > + struct device *dmadev;
> > + struct drm_gem_object *obj;
> > +
> > + if (!dev_is_usb(dev->dev))
> > + return ERR_PTR(-ENODEV);
> > +
> > + dmadev = usb_intf_get_dma_device(to_usb_interface(dev->dev));
> > + if (drm_WARN_ONCE(dev, !dmadev, "buffer sharing not supporte
Hi!
> > > > This is in -next, but I get same behaviour on 5.11; and no, udl does
> > >
> > > Thanks for reporting. We are in the process of fixing the issue. The
> > > latest
> > > patch is at [1].
> > >
> >
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a whil
Hi!
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a while. Then screensaver blanks laptop screen, udl screen
> > blanks too. Upon hitting a key, internal screen shows up, udl does
> > not.
> >
> > I try rerunning xrandr ... --auto, but could not recover it.
> >
Hi!
> >This is in -next, but I get same behaviour on 5.11; and no, udl does
>
> Thanks for reporting. We are in the process of fixing the issue. The latest
> patch is at [1].
>
Thank you, that fixes the DMA issue, and I can use the udl.
...for a while. Then screensaver blanks laptop screen, udl
should use DRM_GEM_SHMEM_DROVER_OPS_USB to initialize their
> instance of struct drm_driver.
>
> Tested by joining/mirroring displays of udl and radeon un der
> Gnome/X11.
Thanks for doing this.
Tested-by: Pavel Machek
Best regards,
Hi!
This is in -next, but I get same behaviour on 5.11; and no, udl does
not work, but monitor is detected:
pavel@amd:~/g/tui/crashled$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x
185
Hi!
> The FSC (Full scale current) setting is not updated properly due to the
> wrong register toggling for WLED5. Also the ILED_SYNC toggle and MOD_SYNC
> toggle sequence is updated as per the hardware team recommendation to fix
> the FSC update and brightness update issue.
If this is phone hard
Hi!
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct file. Since they depend on it for
> core
Hi!
> commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
>
> This function will be needed by the next patch where the driver
> calculates the BW based on driver specific parameters, so export it.
>
> At the same time sanitize the function params, passing the more natural
> link rate inste
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and remove the separate driver entries for:
>
> - TI LP855x backlight driver,
> - TI LP8727 charger driver,
> - TI LP8788 MFD (ADC, LEDs,
On Tue 2020-07-07 11:04:05, Randy Dunlap wrote:
> Drop the doubled word "for".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Jacek Anaszewski
Acked-by: Pavel Machek
(I expect documentation people take this,
Hi!
> > > > Would it not be better to have one st7703 driver that suipports both
> > > > panels?
> > > >
> > > > The driver would need dedicated init functions depending on the panel.
> > > > But a lot could also be shared.
> > >
> > > I guess I can move the code there.
> > In the same process th
On Tue 2020-06-16 09:28:19, Sasha Levin wrote:
> On Tue, Jun 16, 2020 at 12:51:13PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > The driver creates the /dev/dxg device, which can be opened by user mode
> > > > application and handles their ioctls. The I
Hi!
> Thanks for the discussion. I may not be able to immediately answer all of
> your questions, but I'll do my best .
>
Could you do something with your email settings? Because this is not how you
should use
email on lkml. "[EXTERNAL]" in the subject, top-posting, unwrapped lines...
Tha
> > Having said that, I hit one stumbling block:
> > "Further, at this time there are no presentation integration. "
> >
> > If we upstream this driver as-is into some hyperv specific place, and
> > you decide to add presentation integration this is more than likely
> > going to mean you will want
Hi!
> > The driver creates the /dev/dxg device, which can be opened by user mode
> > application and handles their ioctls. The IOCTL interface to the driver
> > is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl
> > definitions). The interface matches the D3DKMT interface on Windows.
> >
On Thu 2020-05-28 14:07:50, Michal Hocko wrote:
> On Thu 28-05-20 14:03:54, Pavel Machek wrote:
> > On Thu 2020-05-28 11:05:17, Michal Hocko wrote:
> > > On Tue 26-05-20 11:10:54, Pavel Machek wrote:
> > > [...]
> > > > [38617.276517] oom_reaper: reaped proc
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it woul
On Thu 2020-05-28 11:05:17, Michal Hocko wrote:
> On Tue 26-05-20 11:10:54, Pavel Machek wrote:
> [...]
> > [38617.276517] oom_reaper: reaped process 31769 (chromium), now
> > anon-rss:0kB, file-rss:0kB, shmem-rss:7968kB
> > [38617.277232] Xorg invoked oom-killer:
; Pavel, care to ack the dts patch?
It looks okay to me (but did not test it yet).
Acked-by: Pavel Machek
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karl
gt; > Signed-off-by: Jean-Jacques Hiblot
> > Acked-by: Pavel Machek
> > Reviewed-by: Daniel Thompson
> > Acked-by: Lee Jones
> > Acked-by: Tony Lindgren
> > Tested-by: Tony Lindgren
> > Signed-off-by: Pavel Machek
> > ---
> > drivers/video/ba
Acked-by: Pavel Machek
Reviewed-by: Daniel Thompson
Acked-by: Lee Jones
Acked-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Pavel Machek
---
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 260
Best regards,
Pavel
commit 81a2daadf8dd6c8e0cbc3b60246932436be3c714
Author: Tomi Valkeinen
Date: Thu Oct 3 10:28:12 2019 +0200
backlight: add led-backlight driver
This patch adds a led-backlight driver (led_
Hi!
> > > It would be good to get LED backlight to work in clean way for 5.6
> > > kernel.
> ...
> > > [If you have an idea what else is needed, it would be welcome; it
> > > works for me in development tree but not in tree I'd like to
> > > upstream.]
> > >
> > > Lee, would you be willing to tak
Hi!
> > * Jean-Jacques Hiblot [700101 00:00]:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backl
backlight driver
This patch adds a led-backlight driver (led_bl), which is similar
to pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single
backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques
Hi!
> > It would be good to get LED backlight to work in clean way for 5.6
> > kernel.
>
> I agree, this is badly needed for many devices.
>
> > [If you have an idea what else is needed, it would be welcome; it
> > works for me in development tree but not in tree I'd like to
> > upstream.]
>
>
. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
Reviewed-by: Daniel Thompson
commit 44b7adbf0b07904e4198ae1d0a763917d1c68a23
Author: Jean-Jacques Hiblot
Date: Thu Oct 3 10:28:10
Hi!
> If you're going to apply them, you need to send out an immutable
> branch for me to pull from.
Aha, its backlight, not LED. I really should not be taking
those. Sorry for the noise, I dropped them from my tree.
Best regards,
On Tue 2019-10-22 17:12:06, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the drm_connector for the panel, that
> the userspace can then use to control and che
Hi!
> If the LED is acquired by a consumer device with devm_led_get(), it is
> automatically released when the device is detached.
>
> Signed-off-by: Jean-Jacques Hiblot
> Acked-by: Pavel Machek
> ---
> drivers/leds/led-class.c | 49
On Mon 2019-09-30 12:09:07, Kiran Gunda wrote:
> Restructure the qcom-wled bindings for the better readability.
>
> Signed-off-by: Kiran Gunda
> Reviewed-by: Bjorn Andersson
> Reviewed-by: Rob Herring
> Acked-by: Daniel Thompson
> Acked-by: Pavel Machek
I applied 1,2 to
1 - 100 of 292 matches
Mail list logo
