I remember reading about the conceptualizing of a Bevy editor of some kind a while ago. I recently tried to find information about its progress but came up empty. What's the current status of the game editor for Bevy?
We've been peeling back the layers of the "editor onion" for awhile now. We've been focused on "foundational engine systems" since Bevy first released. But from here on out, our focus will be shifting. My next big project is "asset preprocessing", which is an important part of editor workflows. Other prominent Bevy developers have started to shift their focus toward preparing Bevy UI for editor scenarios.
I would like to break ground on the editor by the end of the year and have some sort of scene editor MVP proved out. This is ambitious, but I think it is possible given where we are at now. It will be awhile before we have a final editor workflow sorted out, but this will be an open, iterative process that the community will be able to follow along with as it develops.
Mobile is in a pretty good spot at this point: iOS support is pretty stable now. People have already started publishing Bevy iOS apps to the Apple App Store: https://noumenal.app.
Android is close, but not quite there yet. As of this release, Android builds kind of work again. You can build and deploy android apps, but they lose their renderer context if you suspend or resume the app. Audio also doesn't work yet :)
It is something we've been building toward for awhile. We've been focused on core systems like the renderer and ecs for awhile now, but we're finally at the point where we can start moving up the stack.
We will be focusing on scenes, asset workflows, ui, and the editor from here on out (with scenes, asset workflows, and UI being the focus for the next release).
I'd like to have some sort of editor MVP by the end of the year.
The experimental webgl backend support is particularly exciting as browsers still feature-gate WebGPU. Chrome 94 has an origin trial open, but it seems somewhat limited.
I think people are missing the point of supporting this much wattage as a USB-IF standard. There are already 130W power supplies from Dell, so it's going to happen with or without standardization, and I'd rather it happen with. It's also not just laptops that might be powered by this. The article mentions all-in-one computers like Mac might use this, and I could imagine it replacing those awful AC adapters used on monitors with no internal power supply.
The kernel can choose to not support new hardware with old interfaces. If the X11 can't interface with new hardware, that's game over. No broken userspace necessary.
Choosing not to support said interfaces would be the biggest breakage of userspace in 3 decades of Linux history. Such a course of action is nowhere specified by the people who would be responsible. As best I can see you have constructed it from whole cloth from suppositions that seem to be ill considered.
Edit: To be clear breaking user space is when a change happens in the kernel level wherein software that used to work no longer works because the public interface presented differs. If you have evidence that this is actually going to happen other than your own misunderstandings please link it.
The gist of it is that breakage is OK if the userspace isn't open-source and that new uAPIs come around every few years due to the rapid pace development of GPUs.
I worked on Chrome OS graphics for years on and one of my earliest projects was to bring DRM/KMS (then a newish interface) to the Cirrus display card (an ancient card that QEMU happens to emulate).
I don't think the kernel guarantees that if X runs against Linux today, then it will run against the same X on new kernels on new hardware in perpetuity. It's more along the lines of, "if I one calls the read syscall with parameters a, b, c, it won't suddenly require a 4th parameter, or demand they be in a, c, b order."
Anyways, if the kernel developers decided they wanted to invent a brand new uAPI that does graphics, I wouldn't at all be surprised if new GPU drivers only implemented the new uAPI if their target userspace programs all use the new uAPI instead of an older uAPI. Nothing in userspace is "broken" because it will seem to the old uAPI using userspace as if there is no driver for the new GPU.
To be clear in the Wayland fetishists fantasies they wouldn't need to convince people to all switch to wayland circumstances would foreclose on any further debate in reality all players have an incentive to keep existing software working.
If one calls the _ syscall with parameters a b and c it won't suddenly require a 4th or demand they be in a c b order is literally what makes X11 continue working against newer kernels. Providing new functionality wherein if you don't call foo before calling _ with a b and c it fails to perform its function would be functionally the same as changing the order of parameters it would be breaking user space.
I don't see how you could possibly lawyer yourself past that, I don't see that the adults in the room who have to support customers in rhel 8 through 2029 can do anything but keep doing minimum work to keep x and the kernel playing nicely. I don't see how nvidia is going to go from supporting hardware for 10-18 years even on niche hardware to dropping support for X so quickly. I also don't see how you can meaningfully talk about the kernel dropping support for X without basing your discussion on actual kernel developers who logically would talk about kernel foo will be the last to support X probably years before it actually happens. I'm totally sure that python 2 -> 3 took over a decade after it was a completely suitable replacement but we will totally manage to replace X before its replacement is fully baked and the kinks worked out.
In short the whole premise is completely and totally premature wishful thinking by people who want their own way. I'll pour one out for X when its actually and in fact dead.
After years of misleading propaganda about how X11 is "deprecated" now I would expect no less. Besides maybe the main communication channel for development is somewhere else.
Most developer activity related to Linux graphics is in dri-devel, it's been like this for quite a while. The X development channels have been mostly dead outside of discussion of XWayland. I doubt you'll see anyone starting any major new features in X.
I just got my T14s that I customized with 32GB, Ryzen 4750u (8c/16t), and the 400nit display (sadly lost the display lottery, but I didn't notice until I checked the part#). However, it took 60+ days to ship as I ordered it Sep 1st. I suppose the shortage of the Ryzen chips mean long delays for Lenovo laptops which are customized as opposed to the preconfigured variants. All of the preconfigured ones had the 250nit screen and 8-16GB however.
Yes. I have the X13 which is quite similar to the T14s (just smaller) with the same processor/ram and I'm quite happy. Best keyboard I've had on a laptop. Does suspend to ram/suspend to disk/hibernate work you for you though? Using Manjaro on 5.9 kernel and X, and most things work out of the box well enough for my purposes except for suspend/hibernate and I can't find any info online for how to fix it completely.
Added "idle=nomwait amd_iommu=off resume=<swap UUID>" kernel params and this seems to sometimes work but usually not...
And what is your battery life? I get ~5 hrs (up to 6.5hrs with most processes disabled except firefox), with around 6-8 watts discharge rate (using powertop --auto-tune).
Typical trials and tribulations of new hardware with linux. I was thinking of trying out Fedora/Ubuntu/Pop_OS to see how they are.
Totally agree about the keyboard and processor/ram. Originally thought about getting the X13, but I recall the screens options weren't that good, and I prefer the larger size and bigger battery anyways.
As for Linux, I fully intended to dual boot Arch and Windows. Due to circumstance, I am stuck with a tiny 128GB NVMe and so I am using the default Windows for now. I've been watching this playlist of a user installing Arch on their T14s to help prep me on some of the quirks: https://www.youtube.com/watch?v=ihFPynCqfzc&list=PLiKgVPlhUN.... I hope that helps answer some of your questions.
Yeah, for what it's worth--I also am dual booting Windows (solely for games, wine isn't worth the trouble) and I've had absolutely no problems with it. In fact, it's buttery smooth with every game I've tried it on (CK3, Noita, Synthetik, Kenshi, Factorio, etc.).
I first checked which panels were the good ones here: https://www.notebookcheck.net/Lenovo-s-Panel-Lottery-continu..., which indicates Innolux is the panel to get. Then I went to https://support.lenovo.com/ie/en/partslookup and punched in my serial number, located near the bar code on the bottom of the laptop. From the "Parts" tab select the "Commodity Type" as "LCD PANELS" and you should see something like "FRUofAUO14.0FHDIPSAG" indicating I get the "AUO" manufactured LCD panel. If you are particular about getting the Innolux, you can use the substitutes button to figure out the lenovo replacement part number for the desired LCD Panel. For the Innolux on the T14s, it could be ordered here: https://lenovo.encompass.com/item/12401836/Lenovo/01YN156/, but it seems to be currently out of stock.
