https://bugs.kde.org/show_bug.cgi?id=442379
--- Comment #13 from Hector Martin ---
> I find the new behaviour quite unnatural after using it the way it was for so
> long.
That sounds like "I got used to the old way even though it didn't make sense",
which isn't a terr
>
> Best regards,
> =
> Frank Schilder
> AIT Risø Campus
> Bygning 109, rum S14
>
>
> From: Hector Martin
> Sent: Friday, January 19, 2024 10:12 AM
> To: ceph-users@ceph.io
> Subject: [ceph-users] Degraded P
I'm having a bit of a weird issue with cluster rebalances with a new EC
pool. I have a 3-machine cluster, each machine with 4 HDD OSDs (+1 SSD).
Until now I've been using an erasure coded k=5 m=3 pool for most of my
data. I've recently started to migrate to a k=5 m=4 pool, so I can
configure the
https://bugs.kde.org/show_bug.cgi?id=476187
--- Comment #4 from Hector Martin ---
Considering it also only lists CBP for *decoding* and yet it can obviously
decode higher profiles (otherwise it would be useless for the web), I think
that feature list is clearly not exhaustive.
--
You
On 2023/11/23 8:50, Marek Vasut wrote:
> Replace one type of terrible code formatting with a different
> type of terrible code formatting. No functional change.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Bin Meng
> Cc: Hector Martin
> ---
> driver
On 2023/11/22 1:00, Jason Gunthorpe wrote:
> On Tue, Nov 21, 2023 at 03:47:48PM +0900, Hector Martin wrote:
>>> Which is sensitive only to !NULL fwspec, and if EPROBE_DEFER is
>>> returned fwspec will be freed and dev->iommu->fwspec will be NULL
>>> here.
>
On 2023/11/22 1:00, Jason Gunthorpe wrote:
> On Tue, Nov 21, 2023 at 03:47:48PM +0900, Hector Martin wrote:
>>> Which is sensitive only to !NULL fwspec, and if EPROBE_DEFER is
>>> returned fwspec will be freed and dev->iommu->fwspec will be NULL
>>> here.
>
On 2023/11/19 23:13, Jason Gunthorpe wrote:
> On Sun, Nov 19, 2023 at 06:19:43PM +0900, Hector Martin wrote:
>>>> +static int iommu_fwspec_assign_iommu(struct iommu_fwspec *fwspec,
>>>> + struct device *dev,
>>>> +
On 2023/11/19 23:13, Jason Gunthorpe wrote:
> On Sun, Nov 19, 2023 at 06:19:43PM +0900, Hector Martin wrote:
>>>> +static int iommu_fwspec_assign_iommu(struct iommu_fwspec *fwspec,
>>>> + struct device *dev,
>>>> +
On 2023/11/20 21:15, Marek Vasut wrote:
> On 11/20/23 11:45, Hector Martin wrote:
>>
>>
>> On 2023/11/20 11:09, Marek Vasut wrote:
>>> On 11/20/23 00:17, Shantur Rathore wrote:
>>>> On Sun, Nov 19, 2023 at 8:08 PM Marek Vasut wrote:
>>
https://bugs.kde.org/show_bug.cgi?id=477283
Hector Martin changed:
What|Removed |Added
Status|NEEDSINFO |REPORTED
Resolution|WAITINGFORINFO
On 2023/11/20 11:09, Marek Vasut wrote:
> On 11/20/23 00:17, Shantur Rathore wrote:
>> On Sun, Nov 19, 2023 at 8:08 PM Marek Vasut wrote:
>>>
>>> On 10/27/23 01:16, Hector Martin wrote:
>>>> This series is the first of a few bundles of USB fixe
On 2023/11/19 17:10, Hector Martin wrote:
> On 2023/11/15 23:05, Jason Gunthorpe wrote:
>> Allow fwspec to exist independently from the dev->iommu by providing
>> functions to allow allocating and freeing the raw struct iommu_fwspec.
>>
>> Reflow the existing paths
On 2023/11/19 17:10, Hector Martin wrote:
> On 2023/11/15 23:05, Jason Gunthorpe wrote:
>> Allow fwspec to exist independently from the dev->iommu by providing
>> functions to allow allocating and freeing the raw struct iommu_fwspec.
>>
>> Reflow the existing paths
one defers, ops will
be NULL here and the check will fail with EINVAL.
Adding a check for that case here fixes it:
if (!ops)
return driver_deferred_probe_check_state(dev);
With that, for the whole series:
Tested-by: Hector Martin
I can't specifically
one defers, ops will
be NULL here and the check will fail with EINVAL.
Adding a check for that case here fixes it:
if (!ops)
return driver_deferred_probe_check_state(dev);
With that, for the whole series:
Tested-by: Hector Martin
I can't specifically
https://bugs.kde.org/show_bug.cgi?id=476186
--- Comment #3 from Hector Martin ---
I am in fact (150%), but the bad quality looks like compression artifacts, so
it shouldn't be related to scaling/resolution, but rather a codec issue. It
also happens when recording the full screen.
@Noah yes
On 29/10/2023 21.11, Marek Vasut wrote:
> On 10/29/23 08:23, Hector Martin wrote:
>> This makes things work properly on devices with >= 2 TiB
>> capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
>> the capacity will be clamped at 2^32 - 1 sectors.
>>
&
On 29/10/2023 21.04, Marek Vasut wrote:
> On 10/29/23 08:24, Hector Martin wrote:
>> We currently do not really handle altsettings properly, and no driver
>> uses them. Ignore the respective endpoint descriptors for secondary
>> altsettings, to avoid creating dupli
Now that the USB core passes through timeout info to the host
controller, actually hook it up.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 32
drivers/usb/host/xhci.c | 23 +--
include/usb/xhci.h | 14
this is ignored in the
individual drivers.
Signed-off-by: Hector Martin
---
common/usb.c| 21 ++---
drivers/usb/host/ehci-hcd.c | 5 +++--
drivers/usb/host/ohci-hcd.c | 5 +++--
drivers/usb/host/r8a66597-hcd.c | 5 +++--
drivers/usb/host/usb
else if anyone cares :)
This series needs to be applied after [1], since the xHCI changes depend
on changes made there.
[1]
https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
Signed-off-by: Hector Martin
---
Hector Martin (2):
usb: Pass through timeout
to work properly.
Signed-off-by: Hector Martin
---
common/usb.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index aad13fd9c557..90f72fda00bc 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -463,6 +463,15 @@ static int usb_parse_config(struct usb_device
This makes things work properly on devices with >= 2 TiB
capacity. If u-boot is built without CONFIG_SYS_64BIT_LBA,
the capacity will be clamped at 2^32 - 1 sectors.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 132 ---
1 file chan
USB UFI uses fixed 12-byte commands (as does RBC, which is not
supported), but SCSI does not have this limitation. Use the correct
command block lengths depending on the subclass.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 22 ++
1 file changed, 14 insertions
0x9e isn't Read Capacity, it's a service action and the read capacity
command is a subcommand.
READ16 is not 0x48, it's 0x88. 0x48 is SANITIZE and that sounds like we
might have been destroying data instead of reading data. No bueno.
Signed-off-by: Hector Martin
---
drivers/ata/ahci.c | 9
Some USB devices (like hard disks) can take a long time to initially
respond to read/write requests. Explicitly specify a much longer timeout
than normal.
Signed-off-by: Hector Martin
---
common/usb_storage.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/common
ich depends on [1] being applied first. The
USBMS part is logically stand-alone and can be applied in parallel
before that.
[1]
https://lore.kernel.org/u-boot/20231029-usb-fixes-1-v2-0-623533f63...@marcan.st/
Signed-off-by: Hector Martin
---
Hector Martin (4):
scsi: Fix a bunch of S
Some devices like YubiKeys need more time before SET_ADDRESS. The spec
says we need to wait 10ms.
Signed-off-by: Hector Martin
---
common/usb_hub.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index ba11a188ca64..858ada0f73be 100644
--- a/common
.
This is particularly important to avoid regressing some users, since
YubiKeys often *don't* work due to other bugs in the USB stack, but will
start to work once they are fixed.
Signed-off-by: Hector Martin
---
common/usb_kbd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
This mini series fixes one bug, but in the process makes YubiKeys work,
which then regresses people who have one *and* a USB keyboard, since we
only support a single keyboard device.
Therefore patch #1 makes U-Boot ignore YubiKeys, so #2 does not
regress things.
Signed-off-by: Hector Martin
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index db8b8f200250
-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e02a6e300c4f..db8b8f200250 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -671,6 +671,14 @@ int
elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d21e76e0bdb6..e02a6e300c4f 100644
--- a/drivers/usb/host
with unexpected event errors.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 34 ++
include/usb/xhci.h | 2 ++
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses immediate explosions in this part
of the code when timeouts happen, but not the root cause for the
timeout.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 15
=2244305
Signed-off-by: Hector Martin
---
Changes in v2:
- Squashed in a trivial fix for patch #1
- Removed spurious blank line
- Added a longer description to the cover letter
- Link to v1:
https://lore.kernel.org/r/20231027-usb-fixes-1-v1-0-1c879bbcd...@marcan.st
---
Hector Martin (8):
usb
https://bugs.kde.org/show_bug.cgi?id=475472
--- Comment #5 from Hector Martin ---
Yes, 4:2:0 should be the default since a lot of decoders choke on 4:4:4 too. If
offered, 4:4:4 should be an explicit opt-in for users that know their use case
will handle it.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=475472
Hector Martin changed:
What|Removed |Added
Version|23.08.1 |unspecified
CC
https://bugs.kde.org/show_bug.cgi?id=475472
--- Comment #2 from Hector Martin ---
* I meant also width there, not height (which is what the OP reported).
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=476187
Bug ID: 476187
Summary: OpenH264 codec support
Classification: Frameworks and Libraries
Product: KPipeWire
Version: unspecified
Platform: Other
OS: Linux
Status:
https://bugs.kde.org/show_bug.cgi?id=476186
Bug ID: 476186
Summary: Screen recording quality is terrible
Classification: Frameworks and Libraries
Product: KPipeWire
Version: unspecified
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=475472
Hector Martin changed:
What|Removed |Added
Ever confirmed|0 |1
CC
On 27/10/2023 09.36, Marek Vasut wrote:
> On 10/27/23 01:26, Hector Martin wrote:
>> Gah, I should've paid more attention to that rebase. Here's a dumb
>> fixup for this patch. I'll squash it into a v2 if needed alongside
>> any other changes, or if it looks good feel
Gah, I should've paid more attention to that rebase. Here's a dumb
fixup for this patch. I'll squash it into a v2 if needed alongside
any other changes, or if it looks good feel free to apply/squash
it in directly.
---
drivers/usb/host/xhci-ring.c | 1 +
1 file changed, 1 insertion(+)
diff
A bunch of miscellaneous debug messages to aid in working out USB
issues.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
Now that we always check the return value, just return NULL on timeouts.
We can still log the error since this is a problem, but it's not reason
to panic.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
We need to get the DMA address before incrementing the pointer, as that
might move us onto another segment.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci
-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5c2d16b58589..60f2cf72dffa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -669,6 +669,14 @@ int
This isn't going to work, don't pretend it will and then end up timing
out.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60f2cf72dffa
elsewhere but
not a good reason to crash.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d08bb8e2bfba..5c2d16b58589 100644
--- a/drivers/usb/host
and ending up with unexpected event errors.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 34 ++
include/usb/xhci.h | 2 ++
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci
xhci_wait_for_event returns NULL on timeout, so the caller always has to
check for that. This addresses the immediate explosions in this part
of the code, but not the original cause.
Signed-off-by: Hector Martin
---
drivers/usb/host/xhci-ring.c | 15 ++-
drivers/usb/host/xhci.c
other xHCI bugs and adding better debug logs.
I believe this should fix this Fedora bug too:
https://bugzilla.redhat.com/show_bug.cgi?id=2244305
Signed-off-by: Hector Martin
---
Hector Martin (8):
usb: xhci: Guard all calls to xhci_wait_for_event
usb: xhci: Better error handling
https://bugs.kde.org/show_bug.cgi?id=475435
Bug ID: 475435
Summary: default system keyboard model is not correctly set on
Wayland
Classification: Applications
Product: systemsettings
Version: 5.27.8
Platform: Fedora
https://bugs.kde.org/show_bug.cgi?id=465891
Hector Martin changed:
What|Removed |Added
CC||vlad.zahorod...@kde.org
--- Comment #5 from
https://bugs.kde.org/show_bug.cgi?id=465891
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #4 from Hector
https://bugs.kde.org/show_bug.cgi?id=455526
--- Comment #37 from Hector Martin ---
Hmm, it looks like whatever was done to 5.27.7 to fix the non-integer scale
redraw artifacts (which was another major issue) also fixed or significantly
improved blur? I can't reproduce the kind of horrible
https://bugs.kde.org/show_bug.cgi?id=455526
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #32 from Hector
ing weeks. I can probably
get the script done partway through doing this, so I can see how the
distributions evolve over a bunch of data movement.
>
>
> Thanks,
>
> Igor
>
>
> On 28/05/2023 08:31, Hector Martin wrote:
>> So chiming in, I think something is definit
On 29/05/2023 20.55, Anthony D'Atri wrote:
> Check the uptime for the OSDs in question
I restarted all my OSDs within the past 10 days or so. Maybe OSD
restarts are somehow breaking these stats?
>
>> On May 29, 2023, at 6:44 AM, Hector Martin wrote:
>>
>> Hi,
>
Hi,
I'm watching a cluster finish a bunch of backfilling, and I noticed that
quite often PGs end up with zero misplaced objects, even though they are
still backfilling.
Right now the cluster is down to 6 backfilling PGs:
data:
volumes: 1/1 healthy
pools: 6 pools, 268 pgs
>
> Just FYI: allocation probe printing interval is controlled by
> bluestore_alloc_stats_dump_interval parameter.
>
>
> Thanks,
>
> Igor
>
>
>
> On 24/05/2023 17:18, Hector Martin wrote:
>> On 24/05/2023 22.07, Mark Nelson wrote:
>>> Yep,
On 25/05/2023 01.40, 胡 玮文 wrote:
> Hi Hector,
>
> Not related to fragmentation. But I see you mentioned CephFS, and your OSDs
> are at high utilization. Is your pool NEAR FULL? CephFS write performance is
> severely degraded if the pool is NEAR FULL. Buffered write will be disabled,
> and
ave some clearer data
beyond my hunch/deduction after seeing the I/O patterns and the sole
fragmentation number :). Also would be interesting to get some kind of
trace of the bluestore ops the OSD is doing, so I can find out whether
it's doing something pathological that causes more fragmentatio
rom the current 7, the load per MDS will be a
bit less than double.
>
> Emmanuel
>
> On Wed, May 24, 2023 at 2:31 PM Hector Martin wrote:
>
>> On 24/05/2023 21.15, Emmanuel Jaep wrote:
>>> Hi,
>>>
>>> we are currently running a ceph fs clust
On 24/05/2023 21.15, Emmanuel Jaep wrote:
> Hi,
>
> we are currently running a ceph fs cluster at the following version:
> MDS version: ceph version 16.2.10
> (45fa1a083152e41a408d15505f594ec5f1b4fe17) pacific (stable)
>
> The cluster is composed of 7 active MDSs and 1 standby MDS:
> RANK STATE
On 24/05/2023 21.15, Emmanuel Jaep wrote:
> Hi,
>
> we are currently running a ceph fs cluster at the following version:
> MDS version: ceph version 16.2.10
> (45fa1a083152e41a408d15505f594ec5f1b4fe17) pacific (stable)
>
> The cluster is composed of 7 active MDSs and 1 standby MDS:
> RANK STATE
Hi,
I've been seeing relatively large fragmentation numbers on all my OSDs:
ceph daemon osd.13 bluestore allocator score block
{
"fragmentation_rating": 0.77251526920454427
}
These aren't that old, as I recreated them all around July last year.
They mostly hold CephFS data with erasure
On 17/05/2023 03.07, 胡 玮文 wrote:
> Hi Sake,
>
> We are experiencing the same. I set “osd_mclock_cost_per_byte_usec_hdd” to
> 0.1 (default is 2.6) and get about 15 times backfill speed, without
> significant affect client IO. This parameter seems calculated wrongly, from
> the description 5e-3
From: Hector Martin on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2283#note_1277275063
I haven't tested it but I don't see why it wouldn't work.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send
https://bugs.kde.org/show_bug.cgi?id=428424
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #18 from Hector
https://bugs.kde.org/show_bug.cgi?id=442379
--- Comment #8 from Hector Martin ---
(In reply to paul from comment #6)
> As a user of natural/inverted scrolling for years, I would argue that this
> is not actually a bug, but working as expected. "Invert scrolling" means
> inv
https://bugs.kde.org/show_bug.cgi?id=442379
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #7 from Hector
https://bugs.kde.org/show_bug.cgi?id=450551
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #30 from Hector
On 19/12/2022 19.52, Ilias Apalodimas wrote:
> Hi Janne,
>
> [...]
>
function that can be called from board-specific code that sets the
UUID.
Thoughts? Would such a feature be useful on other hardware
platforms?
>>>
>>> efi/boot/bootaarch64.efi is only a fallback if
On 19/12/2022 04.40, Heinrich Schuchardt wrote:
> The MacBooks only have one drive. Why would you want two ESPs on one drive?
The boot model of these machines is fundamentally different from EFI.
There is top-level, built-in multiboot support. The boot stages are:
=== global ===
1. iBoot1
https://bugs.kde.org/show_bug.cgi?id=444029
Hector Martin changed:
What|Removed |Added
CC||mar...@marcan.st
--- Comment #3 from Hector
ore.kernel.org/linux-i2c/mn2pr01mb535821c8058c7814b2f8eedf9f...@mn2pr01mb5358.prod.exchangelabs.com/T/
>
> v1:
> https://lore.kernel.org/linux-i2c/mn2pr01mb535838492432c910f2381f929f...@mn2pr01mb5358.prod.exchangelabs.com/T/
>
> drivers/i2c/busses/i2c-pasemi-core.c | 32 +
On 07/10/2022 09.42, Arminder Singh wrote:
> This patch adds IRQ support to the PASemi I2C controller driver to
> increase the performace of I2C transactions on platforms with PASemi I2C
> controllers. While primarily intended for Apple silicon platforms, this
> patch should also help in
On 01/11/2022 01.15, Justin Forbes wrote:
> On Thu, Oct 27, 2022 at 8:57 AM Hector Martin wrote:
>>
>> drm_fb_build_fourcc_list() currently returns all emulated formats
>> unconditionally as long as the native format is among them, even though
>> not all combinati
https://bugs.kde.org/show_bug.cgi?id=36
Hector Martin changed:
What|Removed |Added
CC||hec...@marcansoft.com
--- Comment #8 from
On 28/10/2022 17.07, Thomas Zimmermann wrote:
> In yesterday's discussion on IRC, it was said that several devices
> advertise ARGB framebuffers when the hardware actually uses XRGB? Is
> there hardware that supports transparent primary planes?
ARGB hardware probably exists in the form of
3b ("drm: Add simpledrm driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
I'm proposing this alternative approach after a heated discussion on
IRC. I'm out of ideas, if y'all don't like this one you can figure it
out for yourseves :-)
Changes since v1:
This v2 moves all th
On 27/10/2022 20.08, Thomas Zimmermann wrote:
> We currently have two DRM drivers that call drm_fb_build_fourcc_list():
> simpledrm and ofdrm. I've been very careful to keep the format selection
> in sync between them. (That's the reason why the helper exists at all.)
> If the drivers start to
On 27/10/2022 19.13, Hector Martin wrote:
> Until now, simpledrm unconditionally advertised all formats that can be
> supported natively as conversions. However, we don't actually have a
> full conversion matrix of helpers. Although the list is arguably
> provided to userspace in prec
Acked-by: Pekka Paalanen
Fixes: 6ea966fca084 ("drm/simpledrm: Add [AX]RGB2101010 formats")
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
---
drivers/gpu/drm/drm_format_helper.c | 15 ---
drivers/gpu/dr
On 21/08/2022 21.35, Daniel Axtens wrote:
> Hi Hector,
>
> Thanks for your patch and for taking the trouble to put it together.
>
>> GRUB is already running out of memory on Apple M1 systems, causing
>> graphics init to fail, as of the latest Git changes. Since dynamic
>> growing of the heap
GRUB is already running out of memory on Apple M1 systems, causing
graphics init to fail, as of the latest Git changes. Since dynamic
growing of the heap isn't done yet, double the default heap size for
now.
Signed-off-by: Hector Martin
---
grub-core/kern/efi/mm.c | 2 +-
1 file changed, 1
Sat 20 Aug 2022 11:32:41 AM UTC By: Hector Martin
As of grub-2:2.06.r297.g0c6c1aff2-1-aarch64 as packaged by Arch Linux ARM
(which is vanilla grub as of that git revision, other than grub.d patches and
trivial packaging-related changes), initializing graphics fails on Apple M1
Pro MacBook 14&qu
https://bugs.kde.org/show_bug.cgi?id=453545
--- Comment #9 from Hector Martin ---
Another workaround is to make the actual command running not be ssh, so konsole
can't see it. For example, you could alias ssh to be `/usr/bin/time ssh`, that
should stop konsole from picking it up.
--
You
https://bugs.kde.org/show_bug.cgi?id=453545
Hector Martin changed:
What|Removed |Added
CC||hec...@marcansoft.com
--- Comment #8 from
-by: Hector Martin
---
drivers/nvme/nvme.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index a305305885ec..5fd2fb9ed6a6 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -27,9 +27,8 @@
#define
https://bugs.kde.org/show_bug.cgi?id=454034
--- Comment #3 from Hector Martin ---
Keep in mind that the confusing setting name was only the last 15 minutes spent
on the issue. I spent months wondering what the colored squares were about in
the first place. It would be helpful to also add
https://bugs.kde.org/show_bug.cgi?id=454034
Bug ID: 454034
Summary: "Allow Color Filters" feature is poorly named,
surprising and unintuitive
Product: konsole
Version: 21.12.3
Platform: Gentoo Packages
OS:
https://bugs.kde.org/show_bug.cgi?id=364321
--- Comment #22 from Hector Martin ---
The UI was there in KDE4. It was lost in KDE5. Do you have a reference as to
why it was removed?
When 57240 was closed, there was no UI and no intent to add an UI. A UI was
later added anyway. Clearly someone
https://bugs.kde.org/show_bug.cgi?id=364321
Hector Martin changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
1 - 100 of 526 matches
Mail list logo
