Linus Fixes Kernel Regression Breaking Witcher 2
jones_supa writes There has been quite a debate around the Linux version of The Witcher 2: Assassins of Kings and the fact that it wasn't really a port. A special kind of wrapper was used to make the Windows version of the game run on Linux systems, similar to Wine. The performance on Linux systems took a hit and users felt betrayed because they thought that they would get a native port. However, after the game stopped launching properly at some point, the reason was actually found to be a Linux regression. Linus quickly took care of the issue on an unofficial Witcher 2 issue tracker on GitHub: "It looks like LDT_empty is buggy on 64-bit kernels. I suspect that the behavior was inconsistent before the tightening change and that it's now broken as a result. I'll write a patch. Serves me right for not digging all the way down the mess of macros." This one goes to the bin "don't break userspace". Linus also reminds of QA: "And maybe this is an excuse for somebody in the x86 maintainer team to try a few games on steam. They *are* likely good tests of odd behavior.."
Real gamers use paper, pencils, and dice.
A developer fixes a bug, and writes a comment on github.
*REAL* gamers emphasize false purity and always seek to exorcize the Other.
Man in charge of kernel fixes kernel when it breaks.
This isn't news. This is what happens.
And if only MS had a similar "never break userspace" rule that applied to even the most unbelievably "casual" of software too.
Hell, I broke four apps just going to 64-bit Windows 8 from... 32-bit Windows 8.
And, I agree. Steam has 1/3rd of my 800 games working on Linux already. If we're not using those as a test-case, then why not? Sure, some will just be multi-platform ports from the same source but likely a lot of code will literally be new ports added just for Linux.
Sad to say, there are probably more games in my Steam library that work natively on Linux now, then there are Windows games on there that'll work under Wine/Crossover/etc.
This, a thousand times this.
The one reason that people like Steve Jobs, Walt Disney, et al made such lasting impacts on not only their companies but the world as well was not because of some great business acumen but because they fixed the problems directly. Sure, they were assholes but ultimately they cared about their products and how customers reacted to them.
Degree milled MBA's don't understand this and would not have given this fix a second thought because a> they couldn't do it and b> the economics didn't make sense because some team would've had to be picked to go out, ascertain the problem, determine the solution which might be a larger fix than a one line change and now you're looking at potentially tens of thousands of dollars expense to fix a bug in a product that isn't even YOURS! It just don't make no economic sense and you'd get dinged and the next stockholders meeting.
You see this in all the industries. Apple after Steve Jobs. Car manufacturers who were eventually run by "businessmen who understood the auto markets" instead of "a car geek who understood business" the entire industry turned into regurgitated pablum with a few occasional bursts of brilliance by a car geek that broke through the red tape. I worked in the consumer electronics industry and have seen first hand how once highly held and coveted products have been turned into cheap commodities by a "fresh executive team" because it's easier to sell to the masses who don't understand the finer details of a product than it is to actually push the envelope and innovate your product into the next generation. Then, when that market dies out completely because the enthusiasts don't want your product because it sucks so the masses don't want it anymore because "it's not cool", the CEOs blame the market for being fickle.
Linux is a mess. I am trying to run Debian Wheezy (stable!) on "fully supported" laptop without any binary blob in the kernel or X server and the number of glitches and bugs is staggering: in two days of use I found that closing the lid doesn't put the laptop to sleep every time, sometimes usb drives aren't listed by 'lsblk' and of course there's no drive in the userland (gnome) then, display manager (gdm3) does not always lock the screen ... I'm giving up.
Those small glitches were the very reason I switched from Linux to Windows. Linux is amazingly buggy on desktop these days.
On one hand, you hear about him flaming out people who break shit in stupid ways.
On the other, you also hear him accepting blame for not checking things properly himself: "Serves me right for not digging all the way down the mess of macros"
Whatever his eccentricities, he sounds quite fair to me.
That is pretty much exactly the opposite of what he said.
Do you mind if I ask what flavor of Linux you were running, what the desktop(s) were and what were the issues you were getting?
That is usually followed by "ah yes, that particular distro is known to be broken, no wonder you were having problems". :)
There have been various issues like the GP comment described, but I won't write a long rant about them. Right now, if I sent a letter to Santa Claus and wanted to have just one issue solved, it would be the problem where the laptop brightness goes in multiple steps under Debian-based distros such as Mint and Ubuntu. Apparently this is because there can be multiple listeners to the backlight event (GPU driver, ACPI driver, OS, BIOS...) and they all do the adjustment without consuming the event. Anyone can observe this problem on a laptop. This is so basic stuff that it cannot be consistently broken like this.
Fix the brightness adjustment. Doooo it. No, I won't do the engineering work to fix it. I have other problems to solve than personally fixing my OS bugs. Windows works fine.
real gamers own the casino. and other large multinational corporations.
Sleep your way to a whiter smile...date a dentist!
The fix and half the quotes attributed to Linus were from me. Apparently people can't figure out who posted which GitHub comment.
This has been a perpetual problem on my Lenovo W510. In one release, it did multiple steps, in the next one, no backlight control at all. I add some kernel command line options and get a crappy 4 step backlight. In the next release, I have to remove those options because my backlight didn't turn on at all with them. Now no working backlight controls (using the FN+Home/End combo on my laptop keyboard). I poke in the /sys sysfs mount at the backlight control that's registered, and can control the backlight that way. I've been following the ACPI development mailing list and this is a perpetual topic of confrontation.
There are lots of proposed fixes that would just resolve it, but they can't be accepted because they break userspace. The whole problem stems from the Laptop bios. In some cases, the bios will advertise ACPI methods to control the backlight, while the GPU driver exposes the controls as well. Depending on the particular bios version (and sometimes even bios settings), the keypress might, in bios, change the brightness, then report the keypress, or it might report the keypress and depend on the OS to use the ACPI interface to control the backlight, or it might depend on the OS to use the GPU driver interface to control the backlight. On some of the systems, the ACPI interface is sometimes broken, and on some, there are multiple controls (for display port and all the other possible display connections built into the system) with no clear way to determine which one to actually use. Some bioses report to work with 'Windows 2012' but actually completely don't. Some ONLY work with that, but report they work with older ones.
From what I recall of the discussion, Windows 8 deals with this by punting the actual event handling to the GPU drivers, expecting them to know how to handle the hardware.
Similar bugs can be seen in Windows if your run a newer version on hardware designed for a previous version (I saw this running Windows 7 on hardware designed for Windows XP, an old Dell laptop).
I find it kinda crazy that every single other feature of my laptop works perfectly (FIngerprint reader, color calibration, wimax radio {none of which I actually ever use}) while backlight which seems so simple (Press button, change brightness) is in a perpetual state of brokenness.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
So would it be fair to say then that this a hardware vendor issue at least in the case of the Lenovo laptop, as it seems that the Microsoft solution is to let just the GPU driver deal with the issue? It seems kind of strange to me though why would the GPU driver have the capability of dealing with the keyboard backlighting feature? Why would the graphics subsystem care about the keyboard? That seems kind of bizarre to me.
I missed the key point of it being keyboard backlight, lol....
Yes, it is very safe to assume that it's the bios vendor (Lenovo in my case, acer, hp, dell, you name it in the other cases). It boils down to there not being a consistent way to control backlights across laptops.
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable