Steamuxulation redux

[krumel]

Not in the terminal output, but in the connection_log.txt. The PingWebSocketCM() (CM06-IAD.cm.steampowered.com:443) failed talking to cm (timeout/neterror - Invalid) errors only appear when earlier steam decides to use UDP, so by forcing TCP mode sign in works better.

 

[cabriofahrer]

Any messages regarding epoll on the terminal?

I am sorry, I don't know what that is.

But running "./steam -tcp" seems to work for the connection. Connects at once. More observations:

1. Half-Life 2 Deathmatch: starting your own server always works, the map loads and moving and shooting around is stable. But this time I did not manage to play on any available servers on the internet. Always when finished downloading maps and objects needed to play on that server, the game crashed with the following output:

3e720000-3e721000 ---p 00001000 00:00 0
3e721000-3e821000 rw-p 00100000 00:00 0
fbffe000-fffde000 ---p 00100000 00:00 0
fffde000-ffffe000 rw-p 00020000 00:00 0           [stack]
ffffe000-fffff000 r-xp 00001000 00:00 0           [vdso]
Segmentation fault
$ ../common/pipes.cpp (766) : CClientPipe::BWriteAndReadResult: BWaitResult failed, disconnected
../common/pipes.cpp (766) : CClientPipe::BWriteAndReadResult: BWaitResult failed, disconnected
../common/pipes.cpp (766) : Fatal assert failed: ../common/pipes.cpp, line 766.  Application exiting.

../common/pipes.cpp (766) : Fatal assert failed: ../common/pipes.cpp, line 766.  Application exiting.

ExceptionHandler::GenerateDump waitpid failed:No child processes
No minidump written, nothing to upload.
_ExitOnFatalAssert

2. TF2: This time I managed to get passed the last limitation, game seemed stable and I could reach the stage of actually logging to a casual server, went through the long process of connecting/loading of TF2, but also right at the stage right before entering the map, game crashed with the same message as above ", ... line 766."

As both games are HL2/source-engine games, it looks like exactly the same problem.

EDIT/UPDATE:

The observation made in HL2 Deathmatch, that game actually works when starting your own server made me test another thing: Trying TF2 in training mode. And yes, success! When choosing an offline training mission (steam-client has to be in online mode though, as otherwise offline training aborts after a while with message "VAC server could not be found"), the game enters in map with bots successfully and playing is stable. Performance absolutely fast, fluid and without stuttering as opposed to i386-wine, where game is unplayable for me by now!

The problem is somewhere related to multiplayer/online gaming.

 

[shkhln]

Linuxulator definitely has issues with socket and network related code. The best course of action would be reporting those to the FreeBSD bug tracker. Ideally, with small and easily testable examples, of course.

without stuttering as opposed to i386-wine, where game is unplayable for me by now!

Honestly, I don't see any reason for stuttering in Wine unless you have a very weak CPU.

 

[shkhln]

Looks like today's beta has finally switched the library UI to the… fucking embedded browser.

(FWIW, Big Picture Mode works fine.)

 

[cabriofahrer]

Linuxulator definitely has issues with socket and network related code. The best course of action would be reporting those to the FreeBSD bug tracker. Ideally, with small and easily testable examples, of course.

So are you are going to do that? I am not qualified enough.

Honestly, I don't see any reason for stuttering in Wine unless you have a very weak CPU.

You got that right. It's an Athlon 64 X2 6400+. But here is the thing: This shows exactly that there really is no need to upgrade your hardware when you get things running under FreeBSD with or without Linuxulator. It is one of the reasons I like FreeBSD so much.

Looks like today's beta has finally switched the library UI to the… fucking embedded browser.

(FWIW, Big Picture Mode works fine.)

So does this automatically upgrade and become available with the next login to steam or do you still have to do something before and load it up to git repo?

 

[cabriofahrer]

Meanwhile I have found and tested another steam game: BrainBread2. It turned out to be another multiplayer game based on the source engine. And surprisingly, as opposed to the others reported before (HL2 Deathmatch and TF2), it had no issues at all. The game did not crash after downloading custom maps, it was perfectly playable and stable until I decided to quit.

I would also like to say another thing regarding this statement:

Linuxulator definitely has issues with socket and network related code. The best course of action would be reporting those to the FreeBSD bug tracker. Ideally, with small and easily testable examples, of course.

I do not understand much about those things, but I have been a regular player of ETQW for years now, a multiplayer game based on the Quake4 engine that has nothing to do with Steam, and it has never had any issues with connection/network, no matter which linux-c6 version or now linux-c7.
So is that the kind of information that should be reported to the bug tracker?

I do not know if my most recent testing result can help you in any way, and it would be nice if you could answer my questions from my previous post.

 

[shkhln]

I do not understand much about those things, but I have been a regular player of ETQW for years now, a multiplayer game based on the Quake4 engine that has nothing to do with Steam, and it has never had any issues with connection/network, no matter which linux-c6 version or now linux-c7.
So is that the kind of information that should be reported to the bug tracker?

Right now that's not enough material for a useful bug report in my opinion.

I do not know if my most recent testing result can help you in any way, and it would be nice if you could answer my questions from my previous post.

If you insist…

So are you are going to do that? I am not qualified enough.

Obviously, I'm only able to report issues I can personally reproduce. So, at the moment, I can't do anything about it.

So does this automatically upgrade and become available with the next login to steam or do you still have to do something before and load it up to git repo?

1. Big Picture can be enabled by selecting View -> Big Picture Mode in menu. It's a complete alternative UI intended for gaming on a coach in front of a TV scenario.
2. The Beta participation can be chosen through Account settings, see https://support.steampowered.com/kb_article.php?ref=7021-EIAH-8669&l=english. Do note though, the only reason I have this enabled in the first place is that I want an opportunity to catch issues as early as possible.

 

[cabriofahrer]

Obviously, I'm only able to report issues I can personally reproduce. So, at the moment, I can't do anything about it.

I am sorry I can only do so much. But with the information I gave you, you could install the three games (TF2, HL2 Deathmatch and BrainBread2) and then be able to reproduce the issues yourself. In the future I can test more games and report my experience to you.

 

[shkhln]

Looks like today's beta has finally switched the library UI to the… fucking embedded browser.

Curiously enough, although I've identified 3 related Linux emulation bugs (PR 240989, PR 240990, PR 240991), the new library UI only started working today after yet another Steam update. Let's hope Valve won't break it in the future.

 

[cabriofahrer]

Thank you for this update. On my side I can only report that shortly after my last post I installed Counter Stike Global Offensive, but that would not even start, which is strange, as it is a source engine game like TF2, HL2 Deathmatch or Brainbread.

 

[shkhln]

To clarify a bit, I'm not quite happy with my futex workaround, so I didn't commit it to the repo.

Counter Stike Global Offensive, but that would not even start

Logs? Anything?

 

[cabriofahrer]

Which logs should I look for? (Names and paths?) Or just the terminal output?

 

[shkhln]

Terminal output.

 

[cabriofahrer]

Terminal output.

Sorry, did not have time until now to get back on that. This is how much I could get, tell me if I should run once again with unlimited scrollback in terminal.
I also want to point out that now, even running ./steam -tcp does not work at once anymore, had to make several attempts to log in.

 

[shkhln]

That would be much more helpful if you didn't edit out all relevant information…

 

[cabriofahrer]

This is the complete output:

 

[shkhln]

Did you disable the Steam overlay in the settings? If not, then disable it. I should probably block it altogether for now.

 

[cabriofahrer]

Yes, Steam overlay in the settings is disabled.

 

[shkhln]

I've seen multiple people suggest that adding "-nojoy" to the game launch options might help (look for Game Properties -> General -> Set Launch Options button). Does it?

 

[cabriofahrer]

No, just tried that and it doesn't. Still segmentation fault in the end.

 

[shkhln]

Curiously enough, although I've identified 3 related Linux emulation bugs (PR 240989, PR 240990, PR 240991), the new library UI only started working today after yet another Steam update. Let's hope Valve won't break it in the future.

Meanwhile, a fix for PR 240989 was committed to CURRENT by yuripv@. We are probably a year or so away from the release of FreeBSD 13, but it's good to see that dealt with anyway. For now, as a fallback for FreeBSD 12, I've added yet another workaround to my repo, although it's obviously a much inferior solution to a proper fix.

The embedded web browser is still disabled by default, so please set STEAM_BROWSER environment variable to 1 to use it. Also note that Chromium's (that's what Steam uses internally for a browser component) sandbox is deactivated, Linuxulator can't handle it currently.

 

[drozdowsky]

shkhln First, thank you for your job I believe that Linux compatibility is the only acceptable option for running steam (beside official FBSD steam client).
Do you think it will be possible to port Proton to FreeBSD (if there was enough traction from FreeBSD community)?
Does Linux layer has some limitations that make running Linux most games from steam impossible? Or is it mostly just a matter of glueing proper libraries together?

Also lately I have heard from friend that have Linux box and he passes through GPU (via OVMF) to VM with win10 guest and he is gaming on win10 guest... pretty cool.
Maybe you know is it possible on FreeBSD? From what I have heard bhyve supports GPU passthrough on FBSD and bhyve supports win10 as a guest but they do not work together. YET.

 

[shkhln]

Do you think it will be possible to port Proton to FreeBSD (if there was enough traction from FreeBSD community)?

Well, that's the objective, but the traction part is somewhat complicated.

Does Linux layer has some limitations that make running Linux most games from steam impossible? Or is it mostly just a matter of gluing proper libraries together?

You mean how many games you would actually be able to play? I have no idea. So far, Linux ports from Feral Interactive seem to come bundled with the CEF-based launcher, which is very challenging to work around; eON (a framework for porting Windows applications) from Virtual Programming is also out of question. Unity games will probably work fine. You might need a workround for sound, see PR 240043.

From what I have heard bhyve supports GPU passthrough

Here you go.

 

[malavon]

Just in case it benefits someone looking at this thread, there's a patch to add 32-bit libraries to the Nvidia driver 4x series.
The patch-nvidia.sh shell script from the emulators/i386-wine(-devel) port no longer works for the newer drivers since there are no 32-bit ones available to download.

I'll probably start experimenting with steam and wine only late december or even next year, but I hope to get there with the stuff in this thread.

 

[shkhln]

danfe@ also decided to exclude some libraries from linux-nvidia-libs, so don't be surprised when Linux Vulkan applications don't run.

Just in case it benefits someone looking at this thread, there's a patch to add 32-bit libraries to the Nvidia driver 4x series.

Interesting… I thought this would conflict with /usr/local/lib32/libGL.so.1 from Mesa, but I don't see it in the i386-wine-devel package.