BedrockOnLinux 2.2.9

Your worlds are now backed up before another Minecraft version opens
them, the graphics card the game runs on can be chosen, and the .deb and
.rpm update themselves. Fullscreen starts are no longer stretched, the
Microsoft sign-in draws on systems without a usable EGL, and a new install
finds its online-login components again.

Added

• The .deb and .rpm update themselves
  (#294). Update
  now, and bedrock-on-linux update, used to send a package install to the
  releases page to download the new file by hand. When the release's own
  package installed the launcher, which the package database says, the
  launcher now downloads the new .deb or .rpm and checks it against the
  release's SHA-256 list. It then installs it with apt-get or dnf (zypper
  and plain rpm too) behind the system's password prompt, and offers to
  restart. A cancelled prompt leaves the package downloaded and says how to
  install it by hand. A package someone else built, such as a distribution's,
  is still left to its package manager.

• A BetterRTX preset manager
  (#166).
  Settings ▸ Tools ▸ BetterRTX and bedrock-on-linux betterrtx list the
  presets published on bedrock.graphics, install one or a .rtpack into the
  selected Minecraft version, and restore the game's own ray tracing
  shaders. A preset replaces three compiled materials, and the game loads
  only materials of its own format. The launcher reads that format from the
  game's files and from the preset's before writing anything, and refuses a
  preset made for another version: today's presets are format 25, made for
  1.26.40, and 1.26.52 loads format 26. The originals are kept beside the
  build, and nothing is written while the game runs.

• Settings ▸ Advanced ▸ Graphics card picks the GPU Minecraft renders on
  (#275). A laptop
  starts every program on its integrated GPU unless told otherwise, so the
  game could run on an Intel iGPU beside an idle GeForce. The setting lists
  the computer's cards, read from sysfs without loading a graphics driver. A
  chosen card is asked for with the variables GNOME and KDE set for Launch
  using Discrete Graphics Card: Mesa's device selection, which then shows
  the game that card alone, DRI_PRIME, and NVIDIA's offload layer for a
  GeForce. Left on Automatic on a laptop whose display runs on its
  integrated GPU beside a discrete one, PLAY says where the choice is.

• Bedrock Editor opens from the launcher
  (#286). Mojang's
  world-building tool is part of the game, started with the protocol URI a
  Windows shortcut to minecraft:?Editor=true hands it. Settings ▸ Tools ▸
  Open Bedrock Editor, the Open Bedrock Editor action of the app menu entry
  and bedrock-on-linux play --editor now start the selected version that way,
  Store builds included: the URI follows the decrypted executable.

• Your worlds, settings and servers follow you from one Minecraft version
  to the next, and can be restored. Every Minecraft build already opened the
  same data, but nothing showed it, and a version change could leave it looking
  lost. Three things are fixed:

  • Automatic backups. Before a version other than the last one opens your
    data, PLAY copies everything you made in that edition (worlds, settings,
    the Servers tab, skins and packs) into a backup. The copy matters: a world
    a newer version has opened is upgraded for good, and one an older version
    opens may not load. The last five are kept, and Settings ▸ Versions ▸
    Backups of your worlds restores any of them. A restore first backs up
    what it replaces, so it can be undone.
  • Preview starts from your worlds. Minecraft Preview keeps a data folder
    of its own: Mojang separates it on purpose, so that a world it upgrades
    never reaches the stable game. It used to open empty. The first Preview
    launch now offers to copy your Minecraft worlds, settings and servers into
    it. It is a copy, and the originals stay with Minecraft. The same section
    can make the copy later.
  • A session played signed out is explained. A Minecraft version that
    does not sign in opens the signed-out profile, which has none of your
    worlds, settings or servers, and that reads as "everything stayed on the
    old version". When the game ran that way while your account's data was
    there to be missed, the launcher says so once the game closes: nothing was
    lost, and it all comes back once the game signs in.

Fixed

• A new install finds its online-login components again. The OpenSSL
  XCurl set, which carries Minecraft's PlayFab traffic and the RNG DLL the
  Wine prefix starts with, is downloaded from the release it was uploaded
  to. The launcher looked for it among the 30 newest releases only, and
  after 30 more were published it ended with "asset
  'openssl-xcurl-set-504bb166e4e7.tar.gz' not published yet" on every
  computer that had not downloaded it before. It now searches every
  release, and so do the Microsoft Store downloader and its WebKitGTK
  runtime, which were next in line.

• A game set to fullscreen that comes up windowed is switched to
  fullscreen (#316).
  Sometimes Minecraft reached its menu in its windowed mode although its
  settings asked for fullscreen, its framed window as large as the screen. The
  window manager's title bar and border then showed as a strip along the top
  and the left, the rest of the picture ran off the screen, and the game
  behaved as a window. Once the menu is up, the helper that already resizes a
  fullscreen start (#283) now recognises that frame and presses F11 for the
  player. The game's own switch then resizes its picture. Checked on a
  virtual display: a windowed game sized to the screen went fullscreen and
  reallocated its picture at 1600×900. A window that the window manager keeps
  below its own title bar, as a normal maximized window is, is left alone.

• The AppImage starts Store builds without a Python on the system. Every
  Minecraft from the Store starts through a small script between xodus-cli
  and Wine. It began with #!/usr/bin/env python3, which looks for the
  system's Python. The AppImage carries its own and puts nothing on PATH,
  so on a system without Python the game could not start. The script now
  names the launcher's own interpreter. It falls back to env python3 only
  when that path cannot be written in a #! line.

• The Xbox Live DLLs from a third party are checked before they go into
  the game. libHttpClient.GDK.dll and XCurl.dll come from a release
  tagged v0.0.0 in another project's repository. Files can be uploaded to
  that tag again, and the launcher copied whatever it served into the game,
  where it runs. They are now pinned to the SHA-256 of the files every
  install has used since June, as is the MinGW libcurl package of the
  GE-Proton path. A changed file is refused instead of installed, and copies
  already in the cache that match keep being used.

• A build on disk starts whatever the build index says. The list of
  Minecraft builds comes from a third party's index (GdkLinks), and PLAY read
  it even for a build already installed. A build the index stopped listing
  was swapped for the newest one, with a download nobody asked for. With the
  index out of reach and no copy of it cached, PLAY failed outright. An
  installed build now starts without the index, and the version picker lists
  the builds on disk whether the index names them or not.

• An interrupted restore can no longer cost a world. Restoring a backup
  copies it in beside the current data, then swaps the two folders with two
  renames. A launcher stopped between the renames left the player's data
  under a temporary name. If the game then started, it made a fresh, empty
  Users folder in its place, and the next restore deleted the player's data
  as a leftover. PLAY now finishes or undoes an interrupted swap before the
  game opens the folder. The player's data goes back, and anything the game
  saved in the fresh folder is kept as a backup that says so. On the
  previous code, the test that reproduces this loses the world.

• A program that crashed no longer reads as a GPU fault. The kernel
  reports a crashed program as "traps: wineserver[4242] general protection
  fault …", in the same words as one of its own faults. Within 40 lines of
  ordinary amdgpu or i915 messages, one of those blocked PLAY as a GPU
  failure until a reboot. Only the kernel's own faults count now.

• Moving the data folder to another drive fails cleanly. A copy cut short
  between two filesystems, by a full drive for instance, had its partial
  copy moved back into the original folder (games/games). A deletion cut
  short after a complete copy lost the files it had already deleted. Each
  move now knows whether its copy completed, and undoes itself accordingly.
  The world backups also move with the rest of the data now.

• Launcher updates are checked against the release before they are
  installed. The AppImage and the .pyz resumed an interrupted download
  under a name that did not carry the version. An update to another release
  could therefore finish with half of each, and nothing checked the result
  before it replaced the running launcher. Each download is now named for
  its release and checked against the release's SHA-256 list.

• Versions with a three-digit minor are named right. The game's
  manifest writes 1.21.120.4 as 1.21.12004.0, and the launcher read
  1.21.12.4 out of it. The patch number is its last two digits.

• BOL_FRAME_RATE=inf means no cap instead of failing the launch with
  an OverflowError.

• On an ARM computer, the launcher says what x86-64 programs need
  (#250). The
  launcher is Python and starts anywhere, but the game, the Wine engine,
  xodus-cli and the WebKitGTK runtime are x86-64. On ARM they run only through
  an x86-64 emulator the kernel hands them to (FEX-Emu, Box64 or qemu-user,
  registered with binfmt_misc). Without one, the first of them failed with
  "Exec format error", which reached the player as a missing WebKitGTK or an
  engine that would not start. Setup now stops first and says to install
  FEX-Emu or Box64. doctor has a cpu line, which names the emulator when
  there is one. Running through an emulator remains untested.

• Minimizing Minecraft with Keep the mouse inside the window on clears
  the screen (#189).
  That setting runs the game in a Wine virtual desktop as large as the
  screen, and the game's title bar is one Wine draws inside it. Its minimize
  button shrank the game to a small bar in the desktop's corner, and the
  desktop stayed over everything with the game's last frame on it. A small
  helper run inside Wine (src/desktop-bridge.c) now tells the launcher when
  the game is minimized. The launcher then minimizes the desktop's window,
  as the window manager's own button would. When that window is back on
  screen, from the taskbar like any other, the game is restored in it.
  Checked with the game on a virtual display: the screen is clear while the
  game is minimized, and the game comes back maximized and drawing.

• The Microsoft sign-in draws on systems whose EGL cannot open a display
  (#273). The
  bundled WebKitGTK runtime was 2.52, which draws every page through EGL, even
  without a GPU. Its page process aborted when the system's EGL could not open
  a display (libglvnd with no EGL vendor installed, or a Mesa built without
  EGL), and the window stayed open and blank. The runtime is now built from
  WebKitGTK 2.54, which Debian published in trixie-security on 2 October. It
  draws the page with no EGL display at all, and brings the security fixes of
  the 2.54 series. A system WebKitGTK older than 2.54 is asked the same two
  questions WebKitGTK asks its EGL; when there is no display, the sign-in uses
  the bundled runtime instead, and doctor says so. Should a WebKitGTK still
  give up, the line its page process prints closes the window and says what
  to install. Reproduced on a virtual display with the EGL vendors hidden:
  2.52 left a grey window, 2.54 drew Microsoft's page.

• The bundled WebKitGTK runtime follows a session to another runtime
  directory. The launcher points the runtime's helper processes at a
  directory under XDG_RUNTIME_DIR, or under /tmp when that variable is
  unset, by rewriting a path inside the library. The rewrite stayed in the
  library, and the next launch looked only for the original path. A session
  with another runtime directory, or none, then failed with "the bundled
  WebKitGTK does not carry the expected helper path". The launcher now
  recognises its own earlier rewrite and moves it again.

• The XCurl request log lands in the logs folder. With Advanced
  diagnostics on, the XCurl shim records one line per HTTP request the game
  makes: curl's result, the HTTP status and the URL, plus the answers of the
  social and Realms services. It wrote them into the game's folder, where
  nobody looks for a log and where the file grew with every session. Each
  session's xcurl.log now moves to the logs folder when the game closes, next
  to minecraft.log. It is the file that tells a Realms Hub upload failing
  with "check your internet connection"
  (#163), or Realms
  greyed out (#313),
  apart from a request the service refused.

• Started in fullscreen, Minecraft is no longer stretched and the mouse
  lines up (#283).
  The game shows its window maximized, creates its frame at that window's
  size, 848 rows on a 900-row screen once the window manager has drawn its
  title bar, and only then makes the window fullscreen. It records the new
  size but never resizes its frame, so the picture was stretched over the
  screen and every click landed where the unstretched picture had the button.
  Toggling fullscreen in game fixed it until the next start. The game does
  resize for any later change of size, so once its menu is up the launcher
  now sends its window one, a row shorter and then the real size, through a
  small helper run inside Wine (src/fullscreen-nudge.c). The helper is aimed
  at the game's window, never at whatever has the keyboard, and only at a
  window that covers its screen. Measured: the game then reallocated to
  1600×899 and 1600×900, and its buttons are drawn at their native size again.
  BOL_FULLSCREEN_NUDGE=0 turns it off.

• Automatic DLL injection waits for the main menu
  (#281). It waited
  for the game's window and the configured delay, but the window opens on the
  loading screen, 13 seconds before the menu on a warm start and over a minute
  before it on a cold one. A client was loaded mid-startup, which a manual
  injection never does, and that is where Flarial's automatic injection lost
  the mouse while its manual one did not. The game writes the feature flags
  it fetches right after drawing its menu, and the injection now waits for
  that too. Measured with a DLL that records when it is loaded: the window
  appeared at 21:18:15, the injection used to come at about 21:18:21, and it
  now came at 21:18:28, with the menu on screen at 21:18:29. A game that never
  writes them is injected anyway, 150 seconds after its window.

• Starting Minecraft without a network says why it cannot
  (#308). A game
  downloaded from the Microsoft Store stays encrypted on disk, and xodus-cli
  fetches the key that decrypts it from Microsoft at every launch. With no
  connection that ended in a Rust panic in the log and a game that closed at
  once. The launch now ends as Minecraft could not start, saying that the
  game needs an internet connection to start, single-player included. The
  README no longer says single-player works offline.

• The Microsoft Store sign-in works where the system's WebKitGTK has no
  TLS support (#249).
  WebKitGTK speaks TLS through a GIO module, glib-networking's, that GIO looks
  for at run time. A Nix or Guix WebKitGTK reached outside the wrapper that
  points GIO at it loads fine, and then the sign-in window shows only "TLS
  support is not available". Before using the system's WebKitGTK, the
  launcher now asks the GIO that library loads, in the environment xodus-cli
  gets, whether it has a TLS backend. When it does not, it uses its bundled
  WebKitGTK runtime, which carries its own, and doctor says so.

• bedrock-on-linux optiscaler works from the portable .pyz. The .pyz
  started the launcher's command line itself, which has no optiscaler
  command, so optiscaler install answered "invalid choice", and an
  OptiScaler installed some other way was not applied when the launcher
  started. Every way of starting the launcher now goes through the same
  entry point.

• The portable .pyz comes back after updating itself. Restart now
  took the .pyz for a launcher started with python3 -m bol, restarted it
  that way, and Python could not find the launcher outside the archive: the
  window closed and nothing came back.

• Switching profile under Nix or Guix no longer stops at a Python error.
  The new window was started by handing the bedrock-on-linux found on
  PATH to Python, and the wrapper both install under that name is a shell
  script. It is now run directly.

• The Legacy compatibility renderer keeps Minecraft's own Max Framerate
  (#314). Since
  2.2.8 the launcher holds the player's limit through vkd3d-proton and sets
  the game's own limiter aside for the session. Proton leaves vkd3d-proton
  out altogether for the legacy renderer, so on the older GPUs that need it
  nothing held the limit any more, and the game ran unpaced from its splash
  screen on. There, the game now keeps pacing itself, as it did before 2.2.8.
  A limit that a session cut short left set aside, by a hard reset or a
  killed launcher, now goes back before the next game starts. Going back to
  an older launcher did not restore it: those do not know where it was kept.

• The game may use swap again on machines with less than 6 GiB of RAM
  (#314). 2.2.8
  keeps Minecraft's memory out of swap while it runs. Where the game and the
  desktop do not fit in RAM together, that left the kernel nothing to reclaim
  but program code and the page cache, the game's and the desktop's, and the
  whole machine could freeze where the game used to slow down. The guard now
  applies from 6 GiB of RAM, twice what Minecraft settles at with a world
  loaded; below that, the game swaps as it did before 2.2.8.

• The update notice gives a Flatpak install the command that updates it
  (#315). The
  README installs the Flatpak with --user. A new bundle installed without
  it became a second, system-wide copy, and the menu kept starting the
  per-user one, still at the old version. Update now now names the bundle
  and the exact command, flatpak install --user or --system according to
  where the running copy is installed. The README says how to remove a copy
  installed the other way.

• Shutting down with Minecraft open no longer blocks the next PLAY.
  Every first launch after such a reboot was refused as an "Unsafe graphics
  session" until the GPU incident was acknowledged. The launcher records each
  game session so that a hard lock leaves a trace, and clears the record once
  the game has closed. At poweroff, systemd stopped the launcher a moment
  before the game, and the record outlived a game that had closed normally
  two seconds later. A SIGTERM or SIGHUP received while Minecraft runs now
  waits up to 20 seconds for the game to close, so the record is cleared,
  and the launcher then stops with the signal it was sent. A session that
  does not close within that time keeps its record, as before. Steam's
  Exit game sends SIGINT and then SIGKILL four seconds later, and that is
  unchanged: a record left that way is still cleared by the next PLAY in the
  same boot. On a Wayland session the launcher window can still be closed
  with its compositor before the game has closed.

• BOL_ALLOW_UNSAFE_GPU=1 gets past an interrupted launch. The override
  let the safety check through, and then the launch stopped at the old
  record anyway with "still marked interrupted", so the documented way
  around the block never worked for it. The record is now replaced with a
  warning that the start is at the player's own risk. The warning also names
  any driver fault the record was hiding from the check. When Steam starts
  the launcher, the refusal says where the variable goes in a shortcut:
  BOL_ALLOW_UNSAFE_GPU=1 %command% at the start of its launch options. In
  the Target field, Steam takes env BOL_ALLOW_UNSAFE_GPU=1 … as the name of
  a program that does not exist, and the shortcut starts nothing.

• Answering Yes to "Minecraft could not start" starts Minecraft. After
  the acknowledgement, PLAY carries on by itself and runs every safety check
  again. Before, the player had to press PLAY a second time. The refusal for
  an interrupted launch no longer tells the player to reboot when they
  already have, or to repair a driver nothing says is broken.

• Restarting into an update no longer blocks PLAY. When an update
  finished while Minecraft was running, Restart now replaced the launcher
  on the spot. The game session it was watching never reached the step that
  clears its GPU safety record, and the restarted launcher, which keeps the
  same process ID, took that record for a session of its own still running:
  every PLAY was refused as "still marked active in this launcher" until the
  launcher was quit and started again. The restart is now offered once the
  game has closed.

Packaging

• A pyproject.toml, for distributions to build the launcher with their
  own Python tooling
  (#306). The wheel
  installs the bedrock-on-linux command, the desktop entry and the icon,
  which is now data/bedrock-on-linux.png, the name the icon theme uses;
  data/icon.png stays as a link to it. Contributed by
  @apteryks, who packages BedrockOnLinux for
  Guix. On top of it, the wheel carries the DLL injector, declares the
  modules the launcher would otherwise pip-install on first start, finds its
  icon under the prefix it was installed to, and leaves updates to pip or to
  the package manager instead of writing a .pyz over pip's script.

• The Nix flake gets PySide6 from the binary cache again
  (#309). It asked
  for Python 3.12, and cache.nixos.org no longer carries PySide6 for it on
  current nixos-unstable, so every update of nixpkgs meant building PySide6
  from source. The flake now uses nixpkgs' default Python, 3.14, with
  PySide6 6.11; the test suite passes on Python 3.14. Contributed by
  @silverhadch.

• packaging is no longer a dependency. The CustomTkinter window
  needed it, and nothing has imported it since the move to PySide6 in
  2.2.2. It was still on the list of modules the launcher checks on
  start, so on a host without it the launcher pip-installed its pinned
  GUI toolkit on top of the one already installed. The AppImage, .deb,
  .rpm and Flatpak no longer bundle it, and the flake and
  pyproject.toml no longer ask for it.

Build provenance

Application artifacts built from source, consuming this
fork's attested, pinned engine and OpenSSL-XCurl set.

Bill of materials (pinned + reproducible):

• Managed engine: wow64-archs-native20 (sha256 2f30533b249954438bf6b425631539c8d8036261ce25cffa0d1ea5d30f1d3e27)
• WineGDK source: 75637b674e1f191e65753663c4c0c32bea05ba6e (prefix sha256 e76d21e706dec9775a41b176b48e69dade034a8248b6f4b9a169dc4c336e2600)
• vkd3d-proton: 3.0.1-nv-dgc (output-hashes sha256 09d22ca93ae4b0a2f99294a43cec6a89a2bd92b96dffb14f2fcc5cf66685b3df)
• OpenSSL-XCurl set: 504bb166e4e7

Verify any file with:

gh attestation verify <file> --repo Wyze3306/BedrockOnLinux

What's Changed

• Add pyproject toml by @apteryks in #306
• flake: use default python3 by @silverhadch in #309

New Contributors

• @apteryks made their first contribution in #306
• @silverhadch made their first contribution in #309

Full Changelog: v2.2.8...v2.2.9