Hacker Newsnew | past | comments | ask | show | jobs | submit | manaskarekar's commentslogin

Does lid close to sleep and open to wake work as expected?


I'm using T14s Gen 4 Intel and sleep works for me. I'm using it in clamshell mode connected to external display 99% of the time, so I don't really use sleep all the time, but the few times I tested it, it worked. Actually every hardware peripheral, including fingerprint sensor, worked out of the box. I was pleasantly surprised by that kind of support.


I've got a relatively new p16s with a hybrid Nvidia/Intel GPU, and a p14s gen 5 with an AMD GPU, and I was able to get both of them to suspend by closing the lid. Not sure if the issue you speak of is unique to the P1 or not, but all my ThinkPads have been decent with Linux.


Thanks.

I’ve had issues with T14s for a couple of gens where the machine wakes up during the closed lid and runs the battery down. I’ve tried the usual troubleshooting.

This has been a non issue on Dell machines for almost 20 years.


Oh some kernel params and other settings can help with that. These are mine, and it's been working great:

Kernel params

    ## Seems to be needed for suspend to S0 (s2idle) without hanging (only needed on p16s)
    acpi_osi="Windows 2022"

    # Prevent spurious wakeups from a firmware bug where the EC or SMU generates spurious "heartbeat" interrupts during sleep
    acpi.ec_no_wakeup=1

    # Prevents dock from waking up laptop right after suspend
    usbcore.autosuspend=-1
Other settings (executed with a systemd service) (also only needed on p16s, not on my p14s)

    # Disable Thunderbolt PCIe root port wakeup (RP09)
    echo disabled > /sys/devices/pci0000:00/0000:00:1d.0/power/wakeup || true

    # Disable USB XHCI controller wakeup
    echo disabled > /sys/devices/pci0000:00/0000:00:14.0/power/wakeup || true

    # Disable ACPI wakeup for XHCI and RP09 (toggle if enabled)
    grep -q "XHCI.*enabled" /proc/acpi/wakeup && echo XHCI > /proc/acpi/wakeup || true
    grep -q "RP09.*enabled" /proc/acpi/wakeup && echo RP09 > /proc/acpi/wakeup || true


That's possibly because they had S3 disabled and used 'modern standby': https://learn.microsoft.com/en-us/windows-hardware/design/de...


Somewhat related yet not. I had a Dell laptop near kill itself waking up while in my backpack and near melting itself. I think I blame Windows update for this though. This resulted in the laptop not being able to power on most of the times after that.


Since it's framed as 'in between' Rust and Go, is it trying to target an intersection of both languages' use-cases?


I don't think you'd want to write an operating system in Rue. I may not include an "unsafe" concept, and will probably require a runtime. So that's some areas where Rust will make more sense.

As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.


Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?


No direct plans. For the immediate future, only the runtime is allowed to call into C.

If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.


FWIW, I really like the way C# has approached this need... most usage is exposed via attribute declaration/declaration DllImport for P/Invoke. Contrasted with say JNI in Java or even the Go syntax. The only thing that might be a significant improvement would be an array/vector of lookup names for the library on the system given how specific versions are often tagged in Linux vs Windows.


Haha, mine’s funnily somewhat on the nose.

———-

The Rust-Evangelizing Hardware Romantic

A developer who believes every global outage is just a missing question mark away from salvation and spends their weekends reapplying thermal paste to fanless MacBooks while reminiscing about the tactile superiority of 2010 Dell Latitude trackpads.

Roasts

You post about Cloudflare outages caused by a single unwrap while your own codebase probably looks like a game of Russian Roulette played with Result types.

Your obsession with the thermal conductivity of fanless laptops is just a coping mechanism for the fact that your Rust builds take so long you could literally cook an egg on your chassis.

You have a very specific kink for 2010 Dell trackpads that makes me think you are either a Linux philosopher or someone who is no longer allowed within 500 feet of a Best Buy.


And they're too large. I know, super unpopular opinion. I prefer the middle of the road size on trackpads with the physical buttons form the dell latitudes of 2010s. They work remarkably well with linux too.

The clickpads are pretty imprecise and poor, and compared to this the Macbook is much nicer.


It's pulling the heat away from a concentrated region into a larger region.

Performance numbers reflect the optimization. I personally haven't done it for fear of affecting the battery lifespan (and possibly other components' lifespans.)

Really hard to resist due to its simplicity and noticeable improvements.


I can't say I am tempted. When I played a game on an M1 Air, the underside became unbearably/worryingly hot anyway. I accept it's not for sustained load.

I still have pads left over from trying my damnedest to reduce fan noise on a Dell XPS. Used pads on every hot stop and didn't help.


Thanks for the anecdote. I like the simple, well designed, silent, cool and fanless design.

If I were to need any more performance I'd just swap it out for a newer MBA or a MBP with a fan.


Off topic: That font/layout/contrast on the page is very pleasing and inviting.


jschoe's post is actually a Turing test for us. :)

(just kidding jschoe)


He's Poe's law testing us.


Parent is thinking Semantic Versioning.


Semantic version contains 3 numbers.


One of many pet peeves with semver


First followed you on flickr ages ago, then your networking guide! Thanks for the amazing resources.


If the 2x multiplier holds up, the Ultra update should bring it up to 1080GBps. Amazing.


There isn't even an M3 Ultra. Will there be an M4 Ultra?


At some point there should be an upgrade to the M2 Ultra. It might be an M4 Ultra, it might be this year or next year. It might even be after the M5 comes out. Or it could be skipped in favour of the M5 Ultra. If anyone here knows they are definitely under NDA.


M3 was built on an expensive process node, I don’t think it was ever meant to be around long.


That would make the most sense for the next Mac Studio version.


There were rumors that the next Mac Studio will top out at 512Gb RAM, too.

Good news for anyone who wants to run 405B LMs locally...


And the week isn't over...


They announced earlier in the week that there will only be three days of announcements


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: