startx user: But soundcard only initializes if use Display Manager {sigh}

I recently installed OpenSuSE on my gateway mt6451 laptop. I happen to have a strong preference to logging in to the console(s) and only starting a gui when and if I’m ready for it… I also strongly dislike graphic login screens, splash images, etc… So I was pleasantly surprised to note that somebody was thoughtful enough to include a hint about needing to make Xorg setuid to use startx in the console error messages the first time I tried to run startx…

What I haven’t been able to find is how to get my soundcard to initialize without using a Display Manager. But while my laptop’s built-in soundcard works in E17 when I start it via the Display Manager, it fails to initialize if I use the “3” kernel option to boot to console.
This affects my ability to play my music with “Music On Console” And when/if I run startx, I can’t play streaming sound from {for example}http://www.thefox.com. Nevermind watch a movie from hulu…

But if I skip the “3” kernel option and start E17 by selecting it from the Display Manager,
I can then do all of those things, because my “HDA ATI SB” soundcard works

What do I gotta do to get OpenSuSE to initialize it without depending on the Display manager???

On 2012-10-03 12:36, jtwdyp wrote:

> What do I gotta do to get OpenSuSE to initialize it without depending
> on the Display manager???

Use a display manager… there is no way around it, I’m afraid. Most desktops are designed with
a DM in thought, and some features simply do not work using startx. That’s how things are.

Worse: with some of the simple display manager some features also fail.

(I learned about this with a bug I reported years ago: they told me to use a DM, and the bug
was closed).


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Did you try to start pulseaudio?


$ start-pulseaudio-x11
or
$ pulseaudio --start

check the volume with alsamixer.

First off, take it easy! :wink:
It’s not the display manager. It’s the desktop which starts pulseaudio from /etc/xdg/autostart. If the desktop is not XDG compliant, you have to start pulseaudio manually or from the DE init scripts. I havent’ used Enlightenment for years and never used E17. I can not help with Enlightenment.

Nonsense!

This only means that it is more convenient to use a DM and stop asking questions. Both xdm (Xsession) and startx (xinitrc) source /etc/X11/xinit/xinitrc.common and run the scripts in /etc/X11/xinitrc.d. For XDG compliant desktops, you might have to export some variables, such as DESKTOP_SESSION. It helps with programs which evaluate these variables, as they won’t be set if you don’t use a DM. Users are expected to open X sessions from a DM. Therefore it is easier and everything gets initialized correctly. But you can of course start X the way you like if you know how to.

On 2012-10-03 20:26, please try again wrote:

> Nonsense!

gnome gpg agent does not work, for example.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

On 2012-10-03 21:43, Carlos E. R. wrote:
> On 2012-10-03 20:26, please try again wrote:
>
>> Nonsense!
>
> gnome gpg agent does not work, for example.

If you start the ssh-agent o gpg agent from inside the session, and save the session status for
next time, the next time I got two agents, three the following time, 4 the next… the agent
had instead to be started by gdm. Just saw it on one of my reports years ago.

Another example:

openSUSE 10.3 would refuse to hibernate when I used wdm. When I switched to gdm, it worked.
Startx would not work, either. Bug 341605. No ConsoleKit support was the culprit.

It is possible that if you know what variables to touch, what programs to start yourself, you
can get it all working. Too complicated for me.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

Yes it does.


********************************************
/etc/X11/xinit/xinitrc: Beginning session setup on Wed Oct  3 12:59:03 PDT 2012...
non-network local connections being added to access control list
/etc/X11/xinit/xinitrc: Setup done, will execute: gnome-session --session=gnome-fallback.
********************************************

gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
GNOME_KEYRING_CONTROL=/tmp/agnelo/keyring-4f7BnK
GNOME_KEYRING_PID=4825
gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
GNOME_KEYRING_CONTROL=/tmp/agnelo/keyring-4f7BnK
SSH_AUTH_SOCK=/tmp/agnelo/keyring-4f7BnK/ssh
GNOME_KEYRING_CONTROL=/tmp/agnelo/keyring-4f7BnK
SSH_AUTH_SOCK=/tmp/agnelo/keyring-4f7BnK/ssh
gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
GNOME_KEYRING_CONTROL=/tmp/agnelo/keyring-4f7BnK
SSH_AUTH_SOCK=/tmp/agnelo/keyring-4f7BnK/ssh
GPG_AGENT_INFO=/tmp/agnelo/keyring-4f7BnK/gpg:0:1

And you didn’t come to the idea … years ago … to write an Xexit script like this one for example:

#! /bin/bash

echo "running $0 ..."

# terminate gnome-keyring daemon
if  "$DISPLAY" ] ; then
        DISP=${DISPLAY#*:} ; DISP=${DISP%.*} ; DISP=$(($DISP * 1))
        if  $DISP -eq 0 ] ; then
                if  "$GNOME_KEYRING_PID" ]; then kill -s SIGTERM $GNOME_KEYRING_PID; fi
                if  "$SSH_AUTH_SOCK" ]; then rm -f -r $(dirname $SSH_AUTH_SOCK) ; fi
        fi
fi


and start the desktop (whether Gnome or another one) with a command like that one (at the end of your xinitrc):

f  "$xsession_exit" ] ; then
	ck-launch-session $command
	exec $xsession_exit
else
	exec ck-launch-session $command
fi

where $xsession_exit refers to the script above.

?

Yes, fortunately!

Maybe, but that’s your own lack of knowledge in this case and not a bug. However I agree that you have to be good to do what you want with Linux … and not only with Linux actually. If I wouldn’t completely rewrite every script (such as xinitrc, Xsession and startx, for example), I would find Linux useless and boring. Linux is like a box of lego. You can build your house like you want. But try moving a stone in Windows! lol!

On 2012-10-03 22:56, please try again wrote:
>
> robin_listas;2492960 Wrote:
>> On 2012-10-03 21:43, Carlos E. R. wrote:
>>> On 2012-10-03 20:26, please try again wrote:
>>>
>>>> Nonsense!
>>>
>>> gnome gpg agent does not work, for example.
>>
>
> Yes it does.

It may start, but it does not work. I had many problems with it.

Even now, with xfce: I had one agent serving an xterm with pine, and another agent serving
thunderbird. A password in one did not work in the other (was not cached across), obviously.
The combination of tools was wrongly starting two agents differently. Now only one is started
by the login or display manager, and it works.

>
>
> robin_listas;2492960 Wrote:
>>
>> If you start the ssh-agent o gpg agent from inside the session, and
>> save the session status for next time, the next time I got two agents, three the following time, 4
>> the next… the agent had instead to be started by gdm. Just saw it on one of my reports
>> years ago.
>>
>
> And you didn’t come to the idea … years ago … to write an Xexit
> script like this one for example:

At the time I was using wdm, it was much simpler to run gdm instead, as they told me to do.

Are you sure the name is “Xexit”? I have never seen that. And none of the people reading that
bugzilla suggested to use that Xexit (I searched just now), and they were devs and maintainers…

Anyway, I prefer to choose my battles, and this was one I did not have time for. So, no, I do
use startx when I need to, but not for my daily use. The devs and packagers are intentionally
not maintaining it and it doesn’t do all it should do for us.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

What can I say? Whatever I say , you’ll have the last word, Carlos. That’s fine with me. lol!

Absolutely sure … because I wrote this script. You can call it “AstalavistaX” if you like.
Stop thinking that devs and maintainers are the most clever people on earth! I wish they would though - because I would sleep longer, spend more time with my wife, make holidays in Granada, etc, etc, etc.

I wouldn’t recommend to use startx either. I just said that it’s not a problem to run the same scripts as Xsession does and compare the environment to export the missing variables. I personally mostly use startx, don’t know why, maybe for historical reasons, but I setup xdm, kdm, gdm (and sometimes lightdm) to do exactly the same thing. If you ask me, the way you start X is irrelevant (OK, I know you didn’t). And how do you start X in NX sessions? Are you running gdm, kdm, xdm … or not even X on the server? And can you use a ssh agent there? Or did you choose other battles?
Nevermind. :wink:

I’m ignorant about solving the first half (i.e. working on console), but in regards to the second part (i.e. getting it to work in X after you’ve used startx from console), have a look here: Back to Basics With X and systemd [Dave Reisner]

I didn’t mean to start a flame war… Sorry for that. I’ll acknowledge that it would in many ways be easier to run a Display Manager. And if I find that something I need won’t work without it. Then when I need to use whatever that is, I will use the DM. I only bothered to ask for help cause doing without sound for my usual day to day use was going to be a real PITA…

Hmmnnn. That might work… I don’t understand the start-up process well enough to know why I don’t have to do something like that when I use startx on my other installed linux… I suspect the debian based ones do that in the rc.d scripts…

I’m thinking it might work if I slipped that into my simplistic .xinitrc. {Like I do with the “synclient TouchpadOff=2” That I use to make my synaptics touchpad mouse tolerable…} But I’d like to be able to use mocp {music on console} to listen to music on the console when I’m not running X… If that can be done at a user prompt {IE: $ not #}, could I get away with adding it to /etc/profile??

That only works if the sound card is “found”… Which, I’m thinking, might be dependent on pulseaudio getting started?

Well E17 is more like an actual “Desktop Environment” than E16 was/is. But it’s still more like a “Window Manager” than anything like KDE or Gnome. So it’s a little like setting up for something like Icewm… But if “pulseaudio --start” works for the sound I’ll be a lot happier.

In fact there are only a couple other things I’d like to solve. And only one of them work for me when I cave in and let the DM initialize…

When I do use the display manager to start E17, then E17’s “menu|system|reboot” & “menu|system|power off” functions work. When I use startx, I can only logout. {Which since I used startx, drops me back into the command shell from which I ran startx where I can then use console methods such as “$ su -c /sbin/poweroff” to accomplish the same thing. }

I don’t suppose you know what I’d need to do to give shutdown/reboot authority to an startx initialized WM/{DE?} like it gets when initialized by the DM???

The other thing doesn’t work even when I use the Display manager. That is GPM on the consoles {tty[1-6]}… I found a tool in yast2 which is supposed to be able to set that up. But it only offers a few mouse type definition names, none of which sounds like the synaptics touchpad to me… In any case none of the few I tried result in a working mouse on the consoles. Suggestions welcome…

But in any case I shall have to reboot with the “3” kernel option again to test the “pulseaudio --start” idea… Thanks for the suggestion.

Well the

pulseaudio --start

method worked But somethings not stable…

I booted without the DM several times… each time I tested if I could play music both before and after startx…

On the first boot sound wasn’t at first working. I ran startx and it still wasn’t working. Logged out and did the

pulseaudio --start

from the console. Eureka! sound played, and alsamixer could adjust the volume. Ran startx again. And could play music from E17 as well. But alsamixergui won’t start. <error claims sound card doesn’t exist.> None of the other installed gui mixers work either. However I can still tweak the sound via the textmode version of alsamixer {either from an xterm, or by logging into another tty.} I note that e17’s mixer gadget starts but
sometimes it’s only connected to dummy output. and sometimes it don’t find any sound channels at all. But on one occasion it just plain worked…

I note that the sound itself has been working without exception since the onetime issue of

pulseaudio --start

and that at no point since has any subsequent use of pulseaudio --start, {neither on console nor from a running E17 session} made any detectable difference.

Could it be that something in the boot process tries to detect the previous state of the sound card and reset it to that condition. Which would only make sense if something in a previous DM initialized session actualy disconnected from the sound card as it shut down??

But none of that matters to me if I continue to be able to play my music. But DOI, I just thought to check. And if the gui mixers don’t see the card, then streaming audio from the web don’t work either… {sigh} Oh well! I guess as long as moc can play my music I won’t need to let the DM run very often

On 2012-10-05 05:06, jtwdyp wrote:

> In fact there are only a couple other things I’d like to solve. And
> only one of them work for me when I cave in and let the DM initialize…
>
> When I do use the display manager to start E17, then E17’s
> “menu|system|reboot” & “menu|system|power off” functions work. When I
> use startx, I can only logout. {Which since I used startx, drops me back
> into the command shell from which I ran startx where I can then use
> console methods such as “$ su -c /sbin/poweroff” to accomplish the same
> thing. }

That’s about the same thing I found with one of the bugzillas I mentioned: I lost those buttons
when I used wdm, and got them back when using gdm (which I did not want to, because it meant to
load many gnome libraries from the start).

> I don’t suppose you know what I’d need to do to give shutdown/reboot
> authority to an startx initialized WM/{DE?} like it gets when
> initialized by the DM???

The reason was “No ConsoleKit”. I think that perhaps you will get that if you use the trick you
got in the3 answer from Tyler_K. The first comment says how to get pulseaudio working. I
thought you had seen that already.

> The other thing doesn’t work even when I use the Display manager. That
> is GPM on the consoles {tty[1-6]}… I found a tool in yast2 which is
> supposed to be able to set that up. But it only offers a few mouse type
> definition names, none of which sounds like the synaptics touchpad to
> me… In any case none of the few I tried result in a working mouse on
> the consoles. Suggestions welcome…

Good question. I tried a bit with my laptop but did not get it working.


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

# systemctl status alsa-restore.service
alsa-restore.service - Restore Sound Card State
          Loaded: loaded (/lib/systemd/system/alsa-restore.service; static)
          Active: inactive (dead) since Sun, 30 Sep 2012 12:25:04 -0700; 4 days ago
         Process: 964 ExecStart=/usr/sbin/alsactl restore (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/alsa-restore.service

This is what I’m using for icewm:

$  cat ~/.icewm/startup

#!/bin/bash
( sleep 1 && conky.sh ) &
/usr/lib/polkit-gnome-authentication-agent-1 &
start-pulseaudio-x11

You can do the same in E17 it it has a startup script. As far as I remember, E16 did. You’d only need start-pulseaudio-x11.

Well now that’s odd… I found another piece of the solution to my sound problem. At least I hope it’s more than just a fluke. but in system.pa I found a commented out section labeled:

X11 modules should not be started from default.pa so that one daemon

can be shared by multiple sessions.

Well since I’m the only guy using my laptop, I’m not all that worried about other sessions. So I edited a copy of system.pa and while X was running, I first did a:

pulseaudio --kill

to get the existing daemon process out of the way. {Gosh every thing on every virtual desktop area in E17 shudders when you do that…}

Then I tried

pulseaudio --start -n --file=/etc/pulse/default.startx

But puleseaudio failed to start. So I tried it as:

pulseaudio -n --file=/etc/pulse/default.startx

and at least it identified the first module that it couldn’t load.

It said module-x11-bell didn’t exist So I re-edited default.startx accordingly. Then it said module-x11-xsmp didn’t exist… But it was willing to start with:


### Publish connection data in the X11 root window
.ifexists module-x11-publish.so
.nofail
load-module module-x11-publish
.fail
.endif

in the initialization file.

Though at first it didn’t seem to have any effect on GUI applications being able to access sound… But the next time I booted, I think something in the boot process must have found something different in the “previous soundcard settings” when it sought to restore them. Only the boot process must have restored them to someplace I couldn’t. So when I fired up E17 via startx, I didn’t get any pop-up error about my soundcard not existing and/or not working. Though E17’s mixer gadget miss-identified the card as “Internal Audio Analog Stereo”. But the main thing was that when I fired up Opera and logged on to hulu, I could watch a movie WITH SOUND. And so far each subsequent boot has restored the sound card to this same functional state.

I suspect though that if I should again let the Display Manager handle the X start-up process, I’ll find the card uncooperative the next time I use startx. I’m not sure if I want to test that theory though. As I’m none too sure that the above daemon restart procedure will work again next time…

Thoughts anyone???

Yeah, even if I did cave in and use a DM, neither GDM nor KDM need apply for the position for similar reasons…

> I don’t suppose you know what I’d need to do to give shutdown/reboot
> authority to an startx initialized WM/{DE?} like it gets when
> initialized by the DM???

The reason was “No ConsoleKit”. I think that perhaps you will get that if you use the trick you
got in the3 answer from Tyler_K. The first comment says how to get pulseaudio working. I
thought you had seen that already.

Actually some of the scripting in the link he posted went over my head… So of course I forgot to remember the suggestion. Which is a shame really, considering if it worked it might have saved a lot of aggravation. But if there is any chance that it might solve the poweroff/reboot problem then it’s worth trying. Accordingly I just pasted that example into a nice new ~/.xserverrc file. whether or not it helps remains to be seen. But either way, thanks for reminding me.

In fact if I didn’t want sound working before I started X, I could probably include it in my ~/.xinitrc Like I do with

 synclient TouchpadOff=2

Except that as you can see,

 linux-i4r5:~ # which start-pulseaudio-x11
which: no start-pulseaudio-x11 in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin)
linux-i4r5:~ #

ifstart-pulseaudio-x11 exists on my system, it’s not even in roots path…

That did in fact solve the poweroff/reboot problem… Of course it also reduces the available virtual consoles (tty) {without stopping X} from 6 to 5. But I guess that’s a small enough price to pay.

Thanks again everybody for all the help.

On 2012-10-07 00:36, jtwdyp wrote:
>
> robin_listas;2493369 Wrote:

>> That’s about the same thing I found with one of the bugzillas I mentioned: I lost those buttons
>> when I used wdm, and got them back when using gdm (which I did not want
>> to, because it meant to load many gnome libraries from the start).
>
> Yeah, even if I did cave in and use a DM, neither GDM nor KDM need
> apply for the position for similar reasons…

Problem is, those two are the most complete. Some of the others lack needed features if you
want sometime to start gnome or kde, and perhaps others like xfce. And with this computer I
have now memory is not that of a problem.

>> The reason was “No ConsoleKit”. I think that perhaps you will get that if you use the trick you
>> got in the3 answer from Tyler_K. The first comment says how to get pulseaudio working. I
>> thought you had seen that already.
>
> Actually some of the scripting in the link he posted went over my
> head… So of course I forgot to remember the suggestion. Which is a
> shame really, considering if it worked it might have saved a lot of
> aggravation. But if there is any chance that it might solve the
> poweroff/reboot problem then it’s worth trying. Accordingly I just
> pasted that example into a nice new ~/.xserverrc file. whether or not it
> helps remains to be seen. But either way, thanks for reminding me.

You should try, it claims that it gets audio working, and you are fighting that one…


Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)