Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

126 participants
7043 discussions

Is Repo Still Scary With Friends in 2026?

by spatial.orca.olhr＠hidingmail.net

“Wait, did you hear that?” That sentence probably sums up half of the repo experience. Not the loot. Not the monsters. Not even the objective. Just a panicked voice in the dark, followed by four people freezing at once because nobody wants to be the first one to move. That’s the strange power of repo. It doesn’t only scare you with what’s on the screen. It scares you through your friends, through bad communication, through the silence between footsteps, and through the one teammate who always makes noise at the worst possible moment. Play now: https://repoonlinegame.com By 2026, a lot of multiplayer horror games have started to blur together. Some rely too heavily on screaming content creators. Others feel scary for an hour, then turn into routine once you understand the AI patterns. So it’s fair to ask: is repo still scary with friends, or has it become one of those games that’s more funny than frightening once the novelty wears off? After spending enough time in repo to know exactly how a “quick run” turns into a 90-minute disaster, I’d say the answer is a little more interesting than yes or no. Repo is still scary, but not in the same way as a solo horror game. Its fear changes shape when you play with other people. Sometimes it becomes weaker. Sometimes it becomes much stronger. And weirdly, the funniest moments are often the reason the horror still works. Why Repo Feels Different From Solo Horror Repo stays scary with friends because its fear doesn’t depend only on isolation. It depends on uncertainty, noise, teamwork pressure, and the feeling that your group can collapse at any second. That makes it a very different kind of horror experience. In a solo horror game, the fear is usually direct. You’re alone, vulnerable, and forced to process every threat by yourself. In repo, you’re technically safer because you have teammates. But that safety is unstable. It can disappear in seconds. Friends make you feel safer, but only at first The first few rounds of repo can trick you into thinking co-op removes the fear. If four people are exploring together, how bad can it be? Pretty bad, actually. Having teammates helps, but it also creates new problems. Someone makes noise. Someone gets separated. Someone panics and gives bad information. Someone carries the wrong item at the wrong time and slows everyone down. In a solo horror game, your mistakes are your own. In repo, the scariest situations often come from a chain reaction of other people’s mistakes. That’s why repo multiplayer horror game sessions feel so unpredictable. You’re not only managing monsters or map hazards. You’re managing human chaos. The tension comes from shared responsibility A lot of horror games are built around survival. Repo adds another layer by making your team responsible for loot, movement, and extraction. You’re not just trying to stay alive. You’re trying to succeed together. That changes the emotional pressure. When you’re carrying something valuable and your team is counting on you not to mess it up, even a small noise can spike your stress. You stop thinking like a horror player and start thinking like someone trying not to be the reason the run fails. That’s a very effective kind of fear because it mixes danger with embarrassment. You’re never fully in control This is one of the smartest things about repo. Even when you understand the game better, you rarely feel fully comfortable. A familiar map doesn’t remove the pressure. It just changes how you prepare for it. The unpredictability of your team keeps the experience alive. That matters in 2026, when many horror games lose their edge once players learn the systems. Repo avoids that because the biggest variable is not the monster. It’s the people beside you. Is Repo More Funny Than Scary With Friends? Yes, repo is often hilarious with friends, but that doesn’t cancel out the horror. It actually strengthens it. The comedy makes players relax just enough for the next scare to hit harder. That balance is one of the main reasons repo works so well. Panic makes everything louder and dumber The best funniest repo moments with friends usually happen when a scary situation is already in progress. Nobody is calm. Nobody is speaking clearly. One person is giving instructions, another is apologizing, and a third is making the situation worse in real time. That chaos is funny because it feels real. In a lot of co-op horror games, the comedy comes from ragdoll physics or random bugs. In repo, the humor often comes from decision-making under pressure. Players say ridiculous things because their brains are overloaded. They blame each other for mistakes they all contributed to. They whisper like survival experts and then immediately sprint into danger. The result is a game that feels social without losing its horror identity. Proximity voice chat changes everything If there’s one system that keeps repo tense even after multiple sessions, it’s proximity voice chat. This feature does more than add immersion. It changes how fear travels through the group. When players are separated, communication becomes messy. Someone hears a warning too late. Someone talks too quietly. Someone screams from another room, and nobody knows if they’re joking or dying. That uncertainty is gold for horror. It also creates an incredible rhythm. Silence becomes threatening. Distant voices become clues. The map feels bigger because your team no longer exists as one safe unit. You’re close enough to help, but not always close enough to fix the problem. Humor lowers your guard This is why repo can still scare experienced players. The game gives you moments to laugh, and those moments reduce your tension just enough to make the next threat land properly. You stop bracing for horror because your friend is busy telling a terrible plan. Then a sound interrupts the joke. Now everybody is quiet. Now the room feels dangerous again. That emotional whiplash is part of what makes repo so memorable. The game doesn’t stay at one intensity level. It keeps shifting between panic and relief, and that movement makes both emotions stronger. What Actually Makes Repo Scary in 2026? Repo remains scary in 2026 because it builds fear through vulnerability, sound, and teamwork failure rather than relying only on cheap jump scares. Even when players know the basics, the game still creates tension through unstable group dynamics. That’s important because horror doesn’t age well if surprise is the only tool. Once you know the tricks, the fear disappears. Repo survives longer because its tension is systemic. Sound design keeps the pressure alive A good horror game knows how to use silence, distant movement, and environmental noise. Repo leans into all of that. The soundscape does a lot of the heavy lifting, especially when your team is already on edge. You hear movement and stop talking. You hear a teammate whisper and assume the worst. You hear something drop in another room and instantly imagine three different disasters. That constant low-level audio tension makes repo feel alive, even when nothing dramatic is happening. Movement and carrying create vulnerability One reason repo works better than many co-op horror games is that the extraction mechanics create physical awkwardness. You’re not always free to move fast, react instantly, or reposition safely. Carrying loot changes how you navigate danger. That’s a huge part of the stress. When players are forced to commit to movement, every bad decision feels heavier. You can’t always run cleanly. You can’t always recover from a mistake. That friction creates tension without needing a scripted scare. Teamwork can break at the worst time This is where semi-coop horror becomes especially effective. Even if everyone technically shares the same goal, people still make selfish or careless choices. Not because they’re malicious, but because panic makes players unreliable. And honestly, that’s terrifying. A teammate who runs off with valuable loot. A friend who insists it’s safe when it clearly isn’t. A player who freezes and blocks a doorway. A rushed extraction where nobody agrees on the plan. These are not cinematic scares. They’re social ones. But they hit hard because they feel plausible every single round. Repo With Friends vs Other Co-op Horror Games Repo still stands out in 2026 because it turns ordinary co-op mistakes into the core of the horror. It doesn’t just place scary things in front of players. It lets players create the tension themselves. Here’s where it differs from a lot of similar games: Repo uses teamwork gameplay as a source of fear, not just a solution Proximity voice chat matters mechanically, not just socially The extraction mechanics force players to take risks under pressure Comedy happens naturally without turning the whole game into parody The fear lasts longer because your teammates stay unpredictable That last point matters most. Most horror games stop being scary once the player learns the map, the monster, or the objective. Repo still has room to surprise because your group keeps changing the shape of every run. One night your team is careful and coordinated. The next night it’s a complete disaster. Same game, totally different emotional experience. So, Is Repo Worth Playing in 2026 If You Have Friends? Yes, repo is worth playing in 2026, especially if you want a horror game that stays tense through social chaos rather than pure isolation. If your favorite horror memories involve shouting at friends, failing together, and somehow laughing through panic, repo absolutely delivers. That doesn’t mean it will scare every group equally. Some teams will turn it into a comedy night. Others will play cautiously and make it much more intense. But that flexibility is part of the appeal. Repo doesn’t force one mood. It gives players a system where fear and humor can keep feeding each other. Repo is a great fit if you enjoy: Co-op horror with strong communication pressure Unpredictable friend-group gameplay Indie horror with personality instead of polished sameness Games where failure becomes part of the fun Tense looting and extraction systems You may bounce off Repo if: You only want pure solo fear You dislike messy teamwork and loud multiplayer sessions You prefer heavily scripted horror over emergent moments You want a game that stays serious all the time Personally, I think that’s exactly why repo has stayed relevant. It understands that horror with friends doesn’t need to copy solo horror. It needs to create a different kind of pressure. Less lonely. More chaotic. More embarrassing. Sometimes even more memorable. And when the game is working at its best, that pressure is very real. Final Thoughts: Is Repo Still Scary With Friends? Yes, repo is still scary with friends in 2026, but its fear comes from a different place than traditional horror. It’s not only about what hunts you in the dark. It’s about what happens when four people try to stay calm, carry valuable loot, and communicate under pressure without falling apart. That’s what makes repo special. It’s scary because your team can fail. It’s funny because your team probably will. And somehow, those two things make each other stronger. If you’re asking is repo worth playing in 2026, the answer is easy if you’ve got the right group. Bring friends who like horror, bad plans, and yelling “I said don’t move” into voice chat. Repo will handle the rest. FAQ 1. Is repo still scary after a few hours? Yes, because repo relies on teamwork mistakes, sound tension, and unpredictable group behavior. Even when the mechanics become familiar, the people around you keep the horror fresh. 2. Is repo better solo or with friends? Repo is much better with friends for most players. The game’s best moments come from proximity voice chat, teamwork failure, and shared panic during extraction. 3. What makes repo different from other co-op horror games? Repo stands out by combining semi-coop horror, jump scares, physical loot handling, and social chaos into one replayable multiplayer loop.

2 days, 5 hours

[PATCH v21 0/4] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Patch-series wide changes since V15: * Fix some major rebasing errors I somehow didn't notice :( * Drop the dependency on LazyInit, use the trick that Alice suggested instead. * Fix dependency ordering so that Tyr can get the vmap stuff first without the other bits. Patch-series wide changes since V16: * Fix ordering one more time (SetOnce::reset() doesn't need to come before adding vmap functions) * Rebase against the latest DeviceContext changes from me that got pushed. Patch-series wide changes since V20: * Lots of Sashiko fixes, excluding the comments that I couldn't prove weren't just bogus. Lyude Paul (4): rust: drm: gem: shmem: Add DmaResvGuard helper rust: drm: gem: shmem: Add vmap functions rust: faux: Allow retrieving a bound Device rust: drm: gem: Introduce shmem::Object::sg_table() rust/kernel/drm/gem/shmem.rs | 547 ++++++++++++++++++++++++++++++++++- rust/kernel/faux.rs | 18 +- 2 files changed, 549 insertions(+), 16 deletions(-) base-commit: 550dc7536644db2d67c6f8cf525bba682fba08d9 -- 2.54.0

2 days, 10 hours

[PATCH] dma-fence: Fix dma_fence_timeline_name() to call get_timeline_name()

by Baineng Shou

dma_fence_timeline_name() incorrectly invokes ops->get_driver_name() instead of ops->get_timeline_name(), so every caller receives the driver name where the timeline name was expected. This is a copy-paste regression that has resurfaced twice. It was originally introduced by commit 62918542b7bf ("dma-fence: Fix sparse warnings due __rcu annotations") when adding the __rcu casts, fixed by commit 033559473dd3 ("dma-fence: Fix safe access wrapper to call timeline name method"), and then accidentally reintroduced by commit e58b4dea9054 ("dma-buf/dma-fence: Add dma_fence_test_signaled_flag()") when both wrappers were refactored to use the new helper. Signed-off-by: Baineng Shou <shoubaineng(a)gmail.com> --- drivers/dma-buf/dma-fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index b3bfa6943a8e..5292d714419b 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1202,7 +1202,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) /* RCU protection is required for safe access to returned string */ ops = rcu_dereference(fence->ops); if (!dma_fence_test_signaled_flag(fence)) - return (const char __rcu *)ops->get_driver_name(fence); + return (const char __rcu *)ops->get_timeline_name(fence); else return (const char __rcu *)"signaled-timeline"; } -- 2.34.1

2 days, 16 hours

How lifestyle affects hormonal balance

by Olga

Hi! I'm curious to know if you pay attention to how your daily habits can impact your health. Nutrition, sleep, stress levels, and recovery are often interrelated. Do you think it's worth starting with lifestyle changes before looking for solutions to maintain hormonal balance?

2 days, 18 hours

[PATCH v2] udmabuf: serialize the sg_table cache under the reservation lock

by Bryam Vargas via B4 Relay

From: Bryam Vargas <hexlabsecurity(a)proton.me> begin_cpu_udmabuf() builds and caches ubuf->sg with an unserialised check-then-set, and end_cpu_udmabuf() reads the same field unlocked. The core invokes both cpu-access hooks without holding the reservation lock and DMA_BUF_IOCTL_SYNC is unlocked, so concurrent SYNC ioctls on a shared udmabuf fd race on ubuf->sg: two begins can both observe NULL and both call get_sg_table(), and the later store orphans the earlier table and its DMA mapping, which release_udmabuf() never frees. Each won race permanently leaks an sg_table and an unbalanced DMA mapping. Serialize both hooks under the buffer's reservation lock, as panfrost and panthor do. Take it interruptibly: the lock can be held across a wait for hardware to finish, so an uninterruptible acquire would park a SYNC ioctl in TASK_UNINTERRUPTIBLE. dma_buf_begin/end_cpu_access() already annotate might_lock() on that lock, so taking it here matches the documented contract. Single-threaded callers are unaffected. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> --- v2: Take the reservation lock interruptibly (dma_resv_lock_interruptible()) in both hooks instead of the uninterruptible dma_resv_lock(), and return the error; the lock can be held across a wait for hardware to finish, so an uninterruptible acquire could park a SYNC ioctl in TASK_UNINTERRUPTIBLE. With a NULL ww_acquire_ctx the call returns only 0 or -EINTR, so a single error check is enough. (Christian König) v1: https://lore.kernel.org/all/20260625-b4-disp-67d1f3db-v1-1-a47fb9edab9e@pro… Same leak-with-dangling-pointer class as CVE-2024-56712 (export_udmabuf() error path) -- a distinct site the 2024 fix does not cover. udmabuf is the only exporter that lazily builds its sg_table cache inside the cpu-access hook without serialising the check-then-set. The exporters that do comparable in-hook cache work all take a lock first: panfrost and panthor dma_resv_lock() (both hooks), omapdrm omap_obj->lock around its lazy page-get, the dma-heaps buffer->lock, and the TTM/GEM exporters (amdgpu, i915, xe) their object's reservation lock. tegra and videobuf2 take no lock here because they only sync an sg_table built earlier, so there is nothing to serialise. Confirmed with an out-of-tree A/B exercising the begin/begin race: this driver built as a module with get_sg_table()/put_sg_table() counting allocations against frees, driven by a userspace racer that creates 3000 udmabufs and fires DMA_BUF_IOCTL_SYNC(SYNC_START) from N threads on each shared fd. The lock serialises the check-then-set identically whether it is taken interruptibly or not; the run below used the reservation lock: arm leaked sg_tables (of 3000 buffers) vulnerable, 4 threads 4761 control, 1 thread 0 patched (resv lock), 4 threads 0 One sg_table and its DMA mapping leak per won race; the single-thread control does not leak, isolating the race; with the lock the lazy-init runs once per buffer (3000 allocations, zero leaked). end_cpu_udmabuf() is locked for the same field too: an unlocked end could otherwise observe the transient IS_ERR store begin makes before resetting ubuf->sg to NULL, and dereference it. In a tighter 5000-iteration loop the unpatched leak runs around 15-20 MB/s of slab. --- drivers/dma-buf/udmabuf.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index bced421c0d65..d6a137f0de1f 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -226,6 +226,10 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, struct device *dev = ubuf->device->this_device; int ret = 0; + ret = dma_resv_lock_interruptible(buf->resv, NULL); + if (ret) + return ret; + if (!ubuf->sg) { ubuf->sg = get_sg_table(dev, buf, direction); if (IS_ERR(ubuf->sg)) { @@ -238,6 +242,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction); } + dma_resv_unlock(buf->resv); + return ret; } @@ -246,12 +252,20 @@ static int end_cpu_udmabuf(struct dma_buf *buf, { struct udmabuf *ubuf = buf->priv; struct device *dev = ubuf->device->this_device; + int ret = 0; + + ret = dma_resv_lock_interruptible(buf->resv, NULL); + if (ret) + return ret; if (!ubuf->sg) - return -EINVAL; + ret = -EINVAL; + else + dma_sync_sgtable_for_device(dev, ubuf->sg, direction); - dma_sync_sgtable_for_device(dev, ubuf->sg, direction); - return 0; + dma_resv_unlock(buf->resv); + + return ret; } static const struct dma_buf_ops udmabuf_ops = { --- base-commit: 7eed1fb17959e721031555e5b5654083fe6a7d02 change-id: 20260625-b4-disp-a9216ef0-d068373aff05 Best regards, -- Bryam Vargas <hexlabsecurity(a)proton.me>

2 days, 18 hours

[PATCH] dma-buf: udmabuf: make list limit unsigned

by Yousef Alhouseen

UDMABUF_CREATE_LIST uses list_limit only as an upper bound for the unsigned entry count supplied by userspace. Negative values have no useful meaning and complicate the bounds check. Make the module parameter unsigned and keep the checked array copy so large counts cannot wrap the allocation size before udmabuf_create() walks the copied list. Signed-off-by: Yousef Alhouseen <alhouseenyousef(a)gmail.com> --- drivers/dma-buf/udmabuf.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index b4078ec84..620113df3 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -16,8 +16,8 @@ #include <linux/vmalloc.h> #include <linux/iosys-map.h> -static int list_limit = 1024; -module_param(list_limit, int, 0644); +static uint list_limit = 1024; +module_param(list_limit, uint, 0644); MODULE_PARM_DESC(list_limit, "udmabuf_create_list->count limit. Default is 1024."); static int size_limit_mb = 64; @@ -469,12 +469,10 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - int limit; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; - limit = READ_ONCE(list_limit); - if (!head.count || limit <= 0 || head.count > limit) + if (!head.count || head.count > READ_ONCE(list_limit)) return -EINVAL; list = memdup_array_user((void __user *)(arg + sizeof(head)), head.count, sizeof(*list)); -- 2.54.0

2 days, 18 hours

[PATCH] udmabuf: serialize the sg_table cache under the reservation lock

by Bryam Vargas via B4 Relay

From: Bryam Vargas <hexlabsecurity(a)proton.me> begin_cpu_udmabuf() builds and caches ubuf->sg with an unserialised check-then-set, and end_cpu_udmabuf() reads the same field unlocked. The core invokes both cpu-access hooks without holding the reservation lock and DMA_BUF_IOCTL_SYNC is unlocked, so concurrent SYNC ioctls on a shared udmabuf fd race on ubuf->sg: two begins can both observe NULL and both call get_sg_table(), and the later store orphans the earlier table and its DMA mapping, which release_udmabuf() never frees. Each won race permanently leaks an sg_table and an unbalanced DMA mapping. Serialize both hooks under the buffer's reservation lock, as panfrost and panthor do. dma_buf_begin/end_cpu_access() already annotate might_lock() on that lock, so taking it here matches the documented contract. Single-threaded callers are unaffected. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> --- Same leak-with-dangling-pointer class as CVE-2024-56712 (export_udmabuf() error path) -- a distinct site the 2024 fix does not cover. udmabuf is the only exporter that lazily builds its sg_table cache inside the cpu-access hook without serialising the check-then-set. The exporters that do comparable in-hook cache work all take a lock first: panfrost and panthor dma_resv_lock() (both hooks), omapdrm omap_obj->lock around its lazy page-get, the dma-heaps buffer->lock, and the TTM/GEM exporters (amdgpu, i915, xe) their object's reservation lock. tegra and videobuf2 take no lock here because they only sync an sg_table built earlier, so there is nothing to serialise. Confirmed with an out-of-tree A/B exercising the begin/begin race: this driver built as a module with get_sg_table()/put_sg_table() counting allocations against frees, driven by a userspace racer that creates 3000 udmabufs and fires DMA_BUF_IOCTL_SYNC(SYNC_START) from N threads on each shared fd. arm leaked sg_tables (of 3000 buffers) vulnerable, 4 threads 4761 control, 1 thread 0 patched (resv lock), 4 threads 0 One sg_table and its DMA mapping leak per won race; the single-thread control does not leak, isolating the race; with the lock the lazy-init runs once per buffer (3000 allocations, zero leaked). end_cpu_udmabuf() is locked for the same field too: an unlocked end could otherwise observe the transient IS_ERR store begin makes before resetting ubuf->sg to NULL, and dereference it. In a tighter 5000-iteration loop the unpatched leak runs around 15-20 MB/s of slab. --- drivers/dma-buf/udmabuf.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index bced421c0d65..702ae13b97d1 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -226,6 +226,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, struct device *dev = ubuf->device->this_device; int ret = 0; + dma_resv_lock(buf->resv, NULL); + if (!ubuf->sg) { ubuf->sg = get_sg_table(dev, buf, direction); if (IS_ERR(ubuf->sg)) { @@ -238,6 +240,8 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, dma_sync_sgtable_for_cpu(dev, ubuf->sg, direction); } + dma_resv_unlock(buf->resv); + return ret; } @@ -246,12 +250,18 @@ static int end_cpu_udmabuf(struct dma_buf *buf, { struct udmabuf *ubuf = buf->priv; struct device *dev = ubuf->device->this_device; + int ret = 0; + + dma_resv_lock(buf->resv, NULL); if (!ubuf->sg) - return -EINVAL; + ret = -EINVAL; + else + dma_sync_sgtable_for_device(dev, ubuf->sg, direction); - dma_sync_sgtable_for_device(dev, ubuf->sg, direction); - return 0; + dma_resv_unlock(buf->resv); + + return ret; } static const struct dma_buf_ops udmabuf_ops = { --- base-commit: 7eed1fb17959e721031555e5b5654083fe6a7d02 change-id: 20260625-b4-disp-67d1f3db-0082918fdcb5 Best regards, -- Bryam Vargas <hexlabsecurity(a)proton.me>

2 days, 21 hours

Unlocking Fun, One Block at a Time: A Dive into Block Blast

by loyal.kingfisher.ghlj＠hidingmail.net

In the vast and ever-growing world of mobile gaming, sometimes the simplest concepts deliver the most satisfying experiences. One such gem is Block Blast, a captivating puzzle game that combines the familiar mechanics of Tetris with a fresh, strategic twist. If you're looking for a relaxing yet engaging way to challenge your mind, then Block Blast might just be your next addiction. https://blockblasts.io/ What is Block Blast? Imagine a 10x10 grid, initially empty. Your goal is to fill this grid with various-shaped blocks that appear at the bottom of the screen, one set of three at a time. The catch? You can't rotate the blocks, and you must place all three given blocks before new ones appear. The objective is to clear lines and columns by filling them completely. Once a line or column is full, it disappears, freeing up space for more blocks and earning you points. The game ends when you can no longer place any of the current blocks on the grid. Gameplay: Simple to Grasp, Challenging to Master The beauty of Block Blast lies in its straightforward mechanics. You simply drag and drop the blocks from the bottom onto the grid. There's no time limit, no frantic swiping – just thoughtful placement. However, don't let the simplicity fool you. As the grid fills up, strategic thinking becomes paramount. You'll quickly learn the importance of anticipating future block shapes and planning your placements to create more clearing opportunities. Should you save that long straight piece for a full column clear, or use it now to open up a crucial corner? These are the delightful dilemmas you'll face. The game encourages a flow state, where you’re constantly evaluating and adapting to the evolving grid. Tips for Becoming a Block Blast Master While the game is easy to pick up, a few strategies can significantly boost your scores and enjoyment: Prioritize Clears: Don't be afraid to clear lines or columns, even if it means using a block in a less-than-ideal spot. Clearing space is crucial for longevity. Think Ahead: Always glance at the next set of blocks. This allows you to plan your current placements with future pieces in mind, creating combos and larger clears. Corners are King: Filling corners and edges can be tricky, so try to tackle them early when you have more space. Don't leave isolated blocks in odd spots. The "L" and "T" Block Dilemma: These oddly shaped blocks can be your best friends or worst enemies. Learn how to integrate them into your clears effectively, often by leaving gaps for them. Practice Makes Perfect: Like any puzzle game, consistent play will improve your spatial reasoning and pattern recognition, leading to higher scores. Conclusion Block Blast offers a delightful blend of relaxation and mental stimulation. Its intuitive design makes it accessible to everyone, while its strategic depth keeps players engaged for countless hours. Whether you're looking for a quick brain break or a long, meditative puzzle session, Block Blast provides a satisfying and rewarding experience. Give it a try, and you might just find your new favorite way to unwind and sharpen your mind, one block at a time.

2 days, 23 hours

Legitimate Recovery Support in 2026 - Primatz Guard

by edwardsjosepht33＠gmail.com

Primatz Guard helps victims of crypto, romance, and investment scams trace funds, investigate fraud, and seek recovery with transparent consultation support.

3 days, 4 hours

dma_fence cleanup/rework

by Christian König

In a recent discussion with Philip and Danilo the question came up what was already tried and never finished to cleanup the dma_fence framework. So here are the different ideas I came with but never fully finished, with the patches itself modernized and rebased on top of drm-misc-next. The main goal of those changes is to make it easier to implement dma_fence backends and don't enforce unnecessary constrains on implementations. As first step the locking around the dma_fence_ops.signaled callback is made consistent by removing the dma_fence_is_signaled_locked() function. This was mostly used by backends itself, but if polling the HW is desired the backends can call their own functions for this directly without going through the dma-fence layer. XE actually seems to be the only driver which make use of that for a bit more handling. For all other cases testing the signaled flag should be enough. Then forcefully calling dma_fence_signaled() is removed from the dma-fence layer and moved into the backend implementations. This allows the backend implementations to cleanup after they have signaled the fence. Such cleanup can include removing now signaled fences from lists, dropping references, starting work etc.... Especially nouveau seems to have some really messy workaround because of that involving the DMA_FENCE_FLAG_USER_BITS and installing callbacks because the reference to the context couldn't be dropped directly after signaling. This can now be cleaned up as far as I can see. In the long term this should also allow reworking the error handling, e.g. removing dma_fence_set_error() and instead giving the error as mandatory parameter to dma_fence_signal(). Then the last piece is dropping calling enable_signaling callback with the dma_fence lock held. This makes it possible for backends to acquire locks which are semantically ordered outside of the dma_fence lock. This is necessary to allows using the dma_fence inline lock in more cases, previously backends used some common external lock for their dma_fences to for example make it possible remove fences from linked lists. Please comment and review, Christian.

3 days, 7 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig