subject:"No Consoles\?\?\?"

Re: x and virtual consoles

2019-09-10 Thread Marc Shapiro


On 8/6/19 12:29 AM, Curt wrote:

On 2019-08-06, Ed  wrote:

On 2019-08-06 09:02+0300, Andrei POPESCU wrote:

On Lu, 05 aug 19, 21:56:55, Ed wrote:

How do you run two login managers though so that you can have two users
share the same computer without having to log out? In other words,
whilst I go and make dinner I want to allow someone else to sit here,
without having to shut applications down?

Some login managers have the "switch user" feature.

Does that feature take the user back to the login screen without leaving
the applications running?



https://wiki.archlinux.org/index.php/LightDM

  LightDM's dm-tool command can be used to allow multiple users to be logged in
  on separate ttys. The following will send a signal requesting that the current
  session be locked and then will initiate a switch to LightDM's greeter,
  allowing a new user to log in to the system.

$ dm-tool switch-to-greeter

Looks promising.

I am another one of those who like to boot to a terminal and then run 
startx (which then runs mate), so this may not apply if you want to boot 
to a DE's login manager, but just to get it out there for those who are 
interested:


My wife, daughter and I each have separate logins on a single box.  On 
the rare occasions that the system gets rebooted, I log on to vt1 and 
run startx (using alias startx='clear; startx -- :0'), my wife logs on 
to vt2 and runs startx (using alias startx='clear; startx -- :1'), and 
my daughter uses vt3 and alias startx='clear; startx -- :2'.  After that 
ctl-alt-f1 gets to my session, ctl-alt-f2 gets to my wife's session and 
ctl-alt-f3 gets to my daughter's session.  All sessions running all the 
time.  The only disadvantage to this is that occasionally a web page 
that my daughter has up will decide that it's time to play music.  Then 
I have to find the offending page and mute it.  Other than that, this 
system has worked for us for years.


Marc

Re: Display multiple virtual consoles on multiple displays

2019-08-22 Thread Michael Stone


On Thu, Aug 22, 2019 at 07:58:51PM +0300, Andrei POPESCU wrote:

It should be possible to run something like

   startx -- :1

to open a second X instance on the virtual console. You have to figure
out how to start the second X on the other display.


It's not that easy with one multiport video card, because you'd have two 
things which each expect to have complete control of the video card. 
With two video cards its a more tractable problem. (Though you'd need to 
manually apportion keyboards & mice.)

Re: Display multiple virtual consoles on multiple displays

2019-08-22 Thread Andrei POPESCU

On Mi, 21 aug 19, 16:01:17, Franklin, Jason wrote:
> Greetings,
> 
> I'm working on a project that requires me to debug a running screen locker.
> 
> Currently, my workflow involves switching between the screen locker and 
> virtual 
> console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This way, I can 
> interact with the screen locker until I hit a break point.  I then return to 
> the first virtual terminal and step through the code.
> 
> This has been very helpful so far, but it's quite slow!
> 
> I have multiple displays, so it seems natural that I'd want to use one 
> display 
> for the screen locker on F7, and one display for vim and gdb on F1.
> 
> Is this possible?  Is it easy or difficult to achieve?

It should be possible to run something like

startx -- :1

to open a second X instance on the virtual console. You have to figure 
out how to start the second X on the other display.

The man page mentions 'startx -- -layout Multihead'. Seems like the 
'-layout' option might be what you need.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Display multiple virtual consoles on multiple displays

2019-08-22 Thread Dan Ritter

rhkra...@gmail.com wrote: 
> On Thursday, August 22, 2019 10:08:16 AM Dan Ritter wrote:
> > Franklin, Jason wrote:
> > > Greetings,
> > > 
> > > I'm working on a project that requires me to debug a running screen
> > > locker.
> > > 
> > > Currently, my workflow involves switching between the screen locker and
> > > virtual console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This
> > > way, I can interact with the screen locker until I hit a break point.  I
> > > then return to the first virtual terminal and step through the code.
> > > 
> > > This has been very helpful so far, but it's quite slow!
> > > 
> > > I have multiple displays, so it seems natural that I'd want to use one
> > > display for the screen locker on F7, and one display for vim and gdb on
> > > F1.
> > > 
> > > Is this possible?  Is it easy or difficult to achieve?
> > 
> > What you want is called multiseat configuration; it assumes that
> > the N monitors are independent, and need to have their own
> > keyboards and mice (though you can fake this with a KVM switch).
> > 
> > Most multiseat configs are X only.
> > 
> > There were two projects to make the VT system multiseat: kmscon
> > and systemd-consoled. Both are defunct, and probably won't work.
> 
> I am an optimist (at least sometimes) ;-)  It seems to me there should be a 
> way to accomplish what you are trying to accomplish.
> 
> Without really having thought this out (or being able to, due to my lack of 
> facile familiarity with virtual machines and such), I wonder if using a VM 
> would give you a way forward -- maybe doing something like:
> 
> Running either vim and gdb or the screen locker (that would require a VM with 
> X capability, which exists, iiuc) in a VM, and then displaying both on the 
> same screen, with, for example, the screen locker in a separate window.  Hmm, 
> I guess I'm not sure that could be done.

No, that's not run by the VT (kernel console) system.

> I guess another thought (maybe somebody mentioned it?) would be to have two 
> separate computers, each with its own monitor and keyboard (or shared with a 
> KVM switch), run the screen locker in one computer, and ssh from the other 
> computer to access vim and gdb on the machine running the screen locker.

Sure. Or, you could wire up an actual serial terminal, or any
random computer with a serial port or a USB-serial converter.

-dsr-

Re: Display multiple virtual consoles on multiple displays

2019-08-22 Thread rhkramer

On Thursday, August 22, 2019 10:08:16 AM Dan Ritter wrote:
> Franklin, Jason wrote:
> > Greetings,
> > 
> > I'm working on a project that requires me to debug a running screen
> > locker.
> > 
> > Currently, my workflow involves switching between the screen locker and
> > virtual console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This
> > way, I can interact with the screen locker until I hit a break point.  I
> > then return to the first virtual terminal and step through the code.
> > 
> > This has been very helpful so far, but it's quite slow!
> > 
> > I have multiple displays, so it seems natural that I'd want to use one
> > display for the screen locker on F7, and one display for vim and gdb on
> > F1.
> > 
> > Is this possible?  Is it easy or difficult to achieve?
> 
> What you want is called multiseat configuration; it assumes that
> the N monitors are independent, and need to have their own
> keyboards and mice (though you can fake this with a KVM switch).
> 
> Most multiseat configs are X only.
> 
> There were two projects to make the VT system multiseat: kmscon
> and systemd-consoled. Both are defunct, and probably won't work.

I am an optimist (at least sometimes) ;-)  It seems to me there should be a 
way to accomplish what you are trying to accomplish.

Without really having thought this out (or being able to, due to my lack of 
facile familiarity with virtual machines and such), I wonder if using a VM 
would give you a way forward -- maybe doing something like:

Running either vim and gdb or the screen locker (that would require a VM with 
X capability, which exists, iiuc) in a VM, and then displaying both on the 
same screen, with, for example, the screen locker in a separate window.  Hmm, 
I guess I'm not sure that could be done.

Maybe someone else has some suggestions along this line, or some other line.

I guess another thought (maybe somebody mentioned it?) would be to have two 
separate computers, each with its own monitor and keyboard (or shared with a 
KVM switch), run the screen locker in one computer, and ssh from the other 
computer to access vim and gdb on the machine running the screen locker.

Re: Display multiple virtual consoles on multiple displays

2019-08-22 Thread Dan Ritter

Franklin, Jason wrote: 
> Greetings,
> 
> I'm working on a project that requires me to debug a running screen locker.
> 
> Currently, my workflow involves switching between the screen locker and 
> virtual 
> console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This way, I can 
> interact with the screen locker until I hit a break point.  I then return to 
> the first virtual terminal and step through the code.
> 
> This has been very helpful so far, but it's quite slow!
> 
> I have multiple displays, so it seems natural that I'd want to use one 
> display 
> for the screen locker on F7, and one display for vim and gdb on F1.
> 
> Is this possible?  Is it easy or difficult to achieve?

What you want is called multiseat configuration; it assumes that
the N monitors are independent, and need to have their own
keyboards and mice (though you can fake this with a KVM switch).

Most multiseat configs are X only.

There were two projects to make the VT system multiseat: kmscon
and systemd-consoled. Both are defunct, and probably won't work.

-dsr-

Re: Display multiple virtual consoles on multiple displays

2019-08-21 Thread Michael Stone


On Wed, Aug 21, 2019 at 04:01:17PM -0400, Franklin, Jason wrote:

I'm working on a project that requires me to debug a running screen locker.

Currently, my workflow involves switching between the screen locker and virtual
console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This way, I can
interact with the screen locker until I hit a break point.  I then return to
the first virtual terminal and step through the code.

This has been very helpful so far, but it's quite slow!

I have multiple displays, so it seems natural that I'd want to use one display
for the screen locker on F7, and one display for vim and gdb on F1.

Is this possible?  Is it easy or difficult to achieve?


Simplest is to ssh from another machine. You also may be able to use 
multiple video cards, but I don't think you can do what you're trying to 
do with multiple monitors attached to one video card.

Display multiple virtual consoles on multiple displays

2019-08-21 Thread Franklin, Jason

Greetings,

I'm working on a project that requires me to debug a running screen locker.

Currently, my workflow involves switching between the screen locker and virtual 
console #1 (/dev/tty1) using Ctrl-Alt-F1 and Ctrl-Alt-F7.  This way, I can 
interact with the screen locker until I hit a break point.  I then return to 
the first virtual terminal and step through the code.

This has been very helpful so far, but it's quite slow!

I have multiple displays, so it seems natural that I'd want to use one display 
for the screen locker on F7, and one display for vim and gdb on F1.

Is this possible?  Is it easy or difficult to achieve?

Thanks,
Jason Franklin

Re: x and virtual consoles

2019-08-06 Thread Ed Neville

On 2019-08-06 10:31-0400, Gene Heskett wrote:
> I did, created a user test, logged in, but when I came back to the 
> machine 10 minutes later, the screen was locked and showing gene as 
> the default login.

dm-tool did work to switch the user. That solves a problem for now. 
Please don't see this as being too picky, but it would be nice for tty 
invoked startx to work like it used to, say if lightdm drops dm-tool at 
some point in the future. ctrl-alt-function keys seems to work in other 
distros, just not debian any longer, something seems different here.

> Getting old isn't for wimps as I'm finding out while looking for some 
> reason to celebrate my 85th in a couple months.  I guess that makes me 
> officially an old fart?

Many, many people failed to make it that far. I wonder what the kernel 
will be like when I get to 85, maybe it will insult me telepathically!

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-06 Thread Gene Heskett

On Tuesday 06 August 2019 09:22:15 Curt wrote:

> On 2019-08-06, deloptes  wrote:
> > Curt wrote:
> >> LightDM's dm-tool command can be used to allow multiple users to be
> >> logged in on separate ttys. The following will send a signal
> >> requesting that the current session be locked and then will
> >> initiate a switch to LightDM's greeter, allowing a new user to log
> >> in to the system.
> >
> > it says multiple users - not the same user
>
> curty@einstein:~/glimmer$ man dm-tool
> 
> switch-to-greeter
>Switch to the greeter suitable for logging into a new
>session.
>
> Says "logging into a new *session*." (emphasis mine).
>
> Let's ask Gene to try it and report back.

I did, created a user test, logged in, but when I came back to the 
machine 10 minutes later, the screen was locked and showing gene as the 
default login.

I've shut it down as I needed to switch cards and boot a stretch that 
works with linuxcnc. But I'm also installing a new upper countershaft 
and bearings for one end of it as a metal spray failed and wrecked the 
bearings. So I bought a new shaft but it had no woodruff key seats cut.
Thats been fun, the shaft is hardened to 60C and carbide tooling is 
dulled instantly.  So I used that tool up trying to EDM the keyway, but 
ran out of broken 1/8" carbide to serve as the electrode. Finally wound 
up with it rigged in my 4 axis gantry, mill and using 3/4" cutoff 
wheels, stacked 4 thick on a dremel arbor being spun by a 1.5 horse 
water cooled motor, at 24k rpms, was able to get it done.

And I'll run the stretch install until a pi4 gets here, if I even get it 
back together before the pi4 arrives. Since new bearings won't be here 
till Thursday late, I'll be Friday pulling those in, then Saturday will 
be wasted putting the spindle back together with new powertwist belting 
hanging down into the drive, then Sunday back to sitting on a very low 
creeper/stool trying to put this shaft back in with belts that may be a 
link short. That involves putting a taperlock hub into the pulley that 
drives those belts, making an even shorter arm allan wrench to tighten 
the taperlock I made because the pulley bore was washed out, and 
tightening that is a multistep process that takes several hours due to 
lack of space to properly run that allen wrench. I can only tighten one 
screw 1/6th turn at time, then rotate to bring the next of 3 screws 
reachable.  But it will be tight enough when done that the lack of a key 
is a never mind. It will not slip.

I haven't over the years, cared for my back all that well, been pushed 
too hard too many times, so 2 crushed disks pinning my sciatic nerves 
isn't fun. Its painfull, and sometimes my legs do not do what my brain 
tells them to, so I may have to kill some time resting to recouperate.

Getting old isn't for wimps as I'm finding out while looking for some 
reason to celebrate my 85th in a couple months.  I guess that makes me 
officially an old fart?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page

Re: x and virtual consoles

2019-08-06 Thread David Wright

On Tue 06 Aug 2019 at 07:11:04 (+0100), Ed wrote:
> On 2019-08-05 16:59-0500, David Wright wrote:
> > Perhaps this is all to do with your DM. I use startx, and since
> > stretch the Xserver runs "on top of" the VC that started it, and
> > as the user, not root. In the past, Xservers ran as root on VC7,
> > VC8, …
> 
> Does lightdm or gdm act as your greeter? I have not reproduced this 
> between xsessions started by tty login, only ever the session started by 
> lightdm crashes.

No, I'm afraid I'm a member of Curt's “ineluctable "just use Mutt"”
association, using startx (though I don't see what Mutt has to do with
the price of fish).

One footnote to my comment, though. After posting it, I looked back
at the line in Xsession and noted that nowadays there's a variable
that might be more useful than the date, so I changed it.

ERRFILE=$HOME/.xsession-errors-$XDG_VTNR
will number them by the VC that the Xserver started on. This could
be fragile if you were to be able to start more than one from the same
VC. OTOH it's predictable as it's available before the Xserver starts,
unlike another alternative which is
ERRFILE=$HOME/.xsession-errors-${DISPLAY#:}

Both these have the advantage over date that they are self-cleaning,
getting overwritten in the normal course of events.

> Tried to force a x session on vt8, but that responds with 'Permission 
> denied' when doing that. I think system d sets up the permissions of 
> tty1 when you use that console:
> 
>   crw--- 1 ed   tty 4,  1 2019-08-06 06:57:48 /dev/tty1

I take what the system throws at me. AIUI the user-owner Xserver has
to run on the tty from which it was started, whereas the older
root-owned ones could open tty7, 8, etc. I don't use the latter
any more.

My guess is that you can't run two user-owned Xservers from the *same*
VC, which is why I trust using $XDG_VTNR above. I take it that this
variable is a new Desktop Group thingy, and its newness is why I
wasn't using it already.

Cheers,
David.

Re: x and virtual consoles

2019-08-06 Thread Curt

On 2019-08-06, Curt  wrote:
>>
>> it says multiple users - not the same user
>>
>>
>
> curty@einstein:~/glimmer$ man dm-tool
>
> switch-to-greeter
>Switch to the greeter suitable for logging into a new
>session.
>
> Says "logging into a new *session*." (emphasis mine).
>
> Let's ask Gene to try it and report back.
>

I guess what Ed would want here is one of the following (because it seems
switch-to-greeter indeed won't get it):

 add-nested-seat
Start an X server inside a session and connect it to a display manager.

 add-local-x-seat DISPLAY_NUMBER
Connect an existing X server to the display manager.

 add-seat TYPE [NAME=VALUE...]
Add a dynamic seat.

Apparently poorly documented (like what is TYPE?):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849072

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-06 Thread Curt

On 2019-08-06, deloptes  wrote:
> Curt wrote:
>
>> LightDM's dm-tool command can be used to allow multiple users to be logged
>> in on separate ttys. The following will send a signal requesting that the
>> current session be locked and then will initiate a switch to LightDM's
>> greeter, allowing a new user to log in to the system.
>
> it says multiple users - not the same user
>
>

curty@einstein:~/glimmer$ man dm-tool

switch-to-greeter
   Switch to the greeter suitable for logging into a new
   session.

Says "logging into a new *session*." (emphasis mine).

Let's ask Gene to try it and report back.

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-06 Thread deloptes

Curt wrote:

> LightDM's dm-tool command can be used to allow multiple users to be logged
> in on separate ttys. The following will send a signal requesting that the
> current session be locked and then will initiate a switch to LightDM's
> greeter, allowing a new user to log in to the system.

it says multiple users - not the same user

Re: x and virtual consoles

2019-08-06 Thread Curt

On 2019-08-06, Ed  wrote:
> On 2019-08-06 09:02+0300, Andrei POPESCU wrote:
>> On Lu, 05 aug 19, 21:56:55, Ed wrote:
>> > 
>> > How do you run two login managers though so that you can have two users 
>> > share the same computer without having to log out? In other words, 
>> > whilst I go and make dinner I want to allow someone else to sit here, 
>> > without having to shut applications down?
>> 
>> Some login managers have the "switch user" feature.
>
> Does that feature take the user back to the login screen without leaving 
> the applications running?
>


https://wiki.archlinux.org/index.php/LightDM

 LightDM's dm-tool command can be used to allow multiple users to be logged in
 on separate ttys. The following will send a signal requesting that the current
 session be locked and then will initiate a switch to LightDM's greeter,
 allowing a new user to log in to the system.

$ dm-tool switch-to-greeter

Looks promising.

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-06 Thread Ed

On 2019-08-06 09:02+0300, Andrei POPESCU wrote:
> On Lu, 05 aug 19, 21:56:55, Ed wrote:
> > 
> > How do you run two login managers though so that you can have two users 
> > share the same computer without having to log out? In other words, 
> > whilst I go and make dinner I want to allow someone else to sit here, 
> > without having to shut applications down?
> 
> Some login managers have the "switch user" feature.

Does that feature take the user back to the login screen without leaving 
the applications running?

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-06 Thread Ed

On 2019-08-05 16:59-0500, David Wright wrote:
> Perhaps this is all to do with your DM. I use startx, and since
> stretch the Xserver runs "on top of" the VC that started it, and
> as the user, not root. In the past, Xservers ran as root on VC7,
> VC8, …

Does lightdm or gdm act as your greeter? I have not reproduced this 
between xsessions started by tty login, only ever the session started by 
lightdm crashes.

Tried to force a x session on vt8, but that responds with 'Permission 
denied' when doing that. I think system d sets up the permissions of 
tty1 when you use that console:

  crw--- 1 ed   tty 4,  1 2019-08-06 06:57:48 /dev/tty1

[   757.147] (--) synaptics: ETPS/2 Elantech Touchpad: touchpad found
[   778.512] (II) AIGLX: Suspending AIGLX clients for VT switch
[   786.321] (II) AIGLX: Resuming AIGLX clients after VT switch
[   786.321] (EE) modeset(0): drmSetMaster failed: Invalid argument
[   786.321] (EE) modeset(0): failed to set mode: Permission denied
[   786.321] (EE)
Fatal server error:
[   786.321] (EE) EnterVT failed for screen 0
[   786.321] (EE)
[   786.321] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[   786.321] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
additional information.
[   786.321] (EE)
[   786.321] (II) AIGLX: Suspending AIGLX clients for VT switch
[   786.376] (EE) Server terminated with error (1). Closing log file.

To eliminate my actions from this, I tried again without telling startx 
which vt to use, and the error above happened on the *second* switch 
back to vt7.

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-06 Thread Andrei POPESCU

On Lu, 05 aug 19, 21:56:55, Ed wrote:
> 
> How do you run two login managers though so that you can have two users 
> share the same computer without having to log out? In other words, 
> whilst I go and make dinner I want to allow someone else to sit here, 
> without having to shut applications down?

Some login managers have the "switch user" feature.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: x and virtual consoles

2019-08-05 Thread David Wright

On Mon 05 Aug 2019 at 21:56:55 (+0100), Ed wrote:
> On 2019-08-05 13:11+0200, deloptes wrote:
> > IMO you can not run multiple X sessions from the same user. I am not 
> > 100% sure, but I can imagine what would happen with the session 
> > manager.
> 
> I have done in the past, one 'ed' would run xfce and another would run 
> evilwm. However, the majority of use would be from 'ed' and a different 
> user account for working from home in.

Sure. This machine is running two X servers as me. As I don't want my
.xsession-errors files to be interleaved, I made one small change to
a system configuration file. In /etc/X11/Xsession I added the line
ERRFILE=$HOME/.xsession-errors-$(/bin/date +%Y%m%d%H%M%S)
but it does mean that I have to sweep them up. I had thought about
distinguishing them by the VC they started on, but haven't got
round to it. Everything else that requires distinguishing uses
$DISPLAY.

> > So if your first session is on vt7 (CTRL) ALT+F7 the next one will be 
> > on
> > (CTRL) ALT+F8.
> 
> This is what I think is expected now if you want tty1 and ctrl-alt-f1 to 
> match:
> 
>   /usr/bin/startx -display :1 -- :1 vt1

Perhaps this is all to do with your DM. I use startx, and since
stretch the Xserver runs "on top of" the VC that started it, and
as the user, not root. In the past, Xservers ran as root on VC7,
VC8, …

> > I have used this only with different users and from the login manager 
> > or
> > from the desktop by starting new user session.
> 
> How do you run two login managers though so that you can have two users 
> share the same computer without having to log out? In other words, 
> whilst I go and make dinner I want to allow someone else to sit here, 
> without having to shut applications down?
> 
> > Doing it from the same user makes no sense IMO. Why would you do this?

Different window managers and desktop configurations. But that's not
the point. It makes no sense to me *not* to be able to do it. It would
be like going back to non-reentrant code when ten instances of emacs
sessions would mean ten executables tying up memory.

> Well, in the weird times when I did, it was a different desktop 
> environment (evilwm for code, xfce for web browsing and mail). Avoids 
> bells and notifications from disturbing me. I'm not doing that these 
> days, now I just don't want to switch user spaces. If it auto-locked, 
> that'd be nice, too, I seem to remember that switching would auto-lock.

Cheers,
David.

Re: x and virtual consoles

2019-08-05 Thread Ed

On 2019-08-05 13:11+0200, deloptes wrote:
> IMO you can not run multiple X sessions from the same user. I am not 
> 100% sure, but I can imagine what would happen with the session 
> manager.

I have done in the past, one 'ed' would run xfce and another would run 
evilwm. However, the majority of use would be from 'ed' and a different 
user account for working from home in.

> So if your first session is on vt7 (CTRL) ALT+F7 the next one will be 
> on
> (CTRL) ALT+F8.

This is what I think is expected now if you want tty1 and ctrl-alt-f1 to 
match:

  /usr/bin/startx -display :1 -- :1 vt1

> I have used this only with different users and from the login manager 
> or
> from the desktop by starting new user session.

How do you run two login managers though so that you can have two users 
share the same computer without having to log out? In other words, 
whilst I go and make dinner I want to allow someone else to sit here, 
without having to shut applications down?

> Doing it from the same user makes no sense IMO. Why would you do this?

Well, in the weird times when I did, it was a different desktop 
environment (evilwm for code, xfce for web browsing and mail). Avoids 
bells and notifications from disturbing me. I'm not doing that these 
days, now I just don't want to switch user spaces. If it auto-locked, 
that'd be nice, too, I seem to remember that switching would auto-lock.

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-05 Thread Ed

On 2019-08-05 09:57-, Curt wrote:
> On 2019-08-04, Ed  wrote:
> > Hello,
> >
> > For years I would happily ctrl-alt-f<1-6> for an additional x.org 
> > session by running 'startx' and another window manager. Until now-ish.
> >
> > What I have observed is that x sessions started from a text console can 
> > cooperate with each other, it seems limited to lightdm/gdm logins only.
> 
> Is this related to this (I can't really understand what you're saying
> here, actually, though everybody else seems to, but what the hell):
> 
> https://bugs.archlinux.org/task/46655

This is seems to be a bug for gnome-terminal, not the x session. But the 
log looks a little familiar.

> https://lists.debian.org/debian-user/2017/10/msg00603.html

This is similar, but not quite as raw as what I experience. I don't have 
to exit one of the x sessions, only start x from tty1 and the greeter 
spawned x will crash.

However, starting an x session on tty1 and then log in on tty2 as 
another user, I can happily switch between tty1 and tty2.

I'll get a log from x tomorrow. I keep wondering if it is down to the 
'-novtswitch' option added to xorg by lightdm. However, these steps at 
the top of the thread will reproduce in a qemu vm, and that uses gdm, 
maybe systemd does something weird with vt7?

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-05 Thread Curt

On 2019-08-05, Felix Miata  wrote:
> Curt composed on 2019-08-05 11:29 (UTC):
>
>> Maybe this is the bug we're looking for:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834270
>
>> Fix (Simon says):
>
>>  * removing the call to /usr/bin/clear_console from ~/.bash_logout 
>>  (console is cleared anyway nowadays)
>>  * replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
>>  ~/.bash_logout
>
> That's the bug and workaround I couldn't remember for my  previous reply. I 
> rarely
> login on vtty1 as a habit going back many moons.

Wading through extraneous material until arrival at the relevant log
files, which may reveal some clue, except those are curiously kept under
wraps.


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-05 Thread Ed

On 2019-08-05 11:11-0400, Felix Miata wrote:
> 
> > Fix (Simon says):
> 
> >  * removing the call to /usr/bin/clear_console from ~/.bash_logout 
> >  (console is cleared anyway nowadays)
> >  * replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
> >  ~/.bash_logout

Why would bash_logout be involved thought? Switching vt should not force 
a logout. I can understand it forcing a lock screen, but not a logout, 
surely?

> That's the bug and workaround I couldn't remember for my  previous reply. I 
> rarely
> login on vtty1 as a habit going back many moons.

That didn't solve it for me, unfortunately. I will try again this week 
with a selection of different Debian versions.

To explain a little more about why I used this heavily, my local user 
'ed' would have a normal xfce desktop, whilst my working from home user 
would match the username at $corp for convenience. The rest of the 
family have their own user accounts and we could work in harmony.

What I've found though, is that this issue doesn't occur with 
Elementary. I've not tested with plain Ubuntu. In a way, if the problem 
exists in Ubuntu or one of the other variants then I may have a delta to 
investigate.

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-05 Thread Felix Miata

Curt composed on 2019-08-05 11:29 (UTC):

> Maybe this is the bug we're looking for:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834270

> Fix (Simon says):

>  * removing the call to /usr/bin/clear_console from ~/.bash_logout 
>  (console is cleared anyway nowadays)
>  * replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
>  ~/.bash_logout

That's the bug and workaround I couldn't remember for my  previous reply. I 
rarely
login on vtty1 as a habit going back many moons.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: x and virtual consoles

2019-08-05 Thread Curt

On 2019-08-04, Ed  wrote:
>
>   1. log in via lightdm/gdm
>   2. switch to a text console
>   3. run startx and use the window manager for a moment or two
>   4. switch back to first session

Maybe this is the bug we're looking for:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834270

Fix (Simon says):

 * removing the call to /usr/bin/clear_console from ~/.bash_logout 
 (console is cleared anyway nowadays)
 * replacing the call to /usr/bin/clear_console with /usr/bin/reset in 
 ~/.bash_logout

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-05 Thread deloptes

Ed wrote:

> For years I would happily ctrl-alt-f<1-6> for an additional x.org
> session by running 'startx' and another window manager. Until now-ish.
> 
> The way to reproduce the problem is as follows:
> 
> 1. log in via lightdm/gdm
> 2. switch to a text console
> 3. run startx and use the window manager for a moment or two
> 4. switch back to first session
> 
> At this point you should be presented with the default login screen
> after the x session crashed.
> 
> What I have observed is that x sessions started from a text console can
> cooperate with each other, it seems limited to lightdm/gdm logins only.
> 
> Something happened between jobs which meant I didn't need to run several
> user accounts at once. It may have been introduced during Jessie or
> Stretch.
> 
> Am I alone, or do other people have this issue also? Am I doing multi
> GUI wrong, is there a modern way to do this that has slipped past me
> without noticing?

IMO you can not run multiple X sessions from the same user. I am not 100%
sure, but I can imagine what would happen with the session manager.

AFAIR if you start a new X session it will take the next virtual available.

So if your first session is on vt7 (CTRL) ALT+F7 the next one will be on
(CTRL) ALT+F8.

I have used this only with different users and from the login manager or
from the desktop by starting new user session.

Doing it from the same user makes no sense IMO. Why would you do this?

regards

Re: x and virtual consoles

2019-08-05 Thread Curt

On 2019-08-04, Ed  wrote:
> Hello,
>
> For years I would happily ctrl-alt-f<1-6> for an additional x.org 
> session by running 'startx' and another window manager. Until now-ish.
>
>
> What I have observed is that x sessions started from a text console can 
> cooperate with each other, it seems limited to lightdm/gdm logins only.

Is this related to this (I can't really understand what you're saying
here, actually, though everybody else seems to, but what the hell):

https://bugs.archlinux.org/task/46655
https://lists.debian.org/debian-user/2017/10/msg00603.html

If not, disregard (there's not really any help in those links I must
admit, either).

> Something happened between jobs which meant I didn't need to run several 
> user accounts at once. It may have been introduced during Jessie or 
> Stretch.
>
> Am I alone, or do other people have this issue also? Am I doing multi 
> GUI wrong, is there a modern way to do this that has slipped past me 
> without noticing?
>


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: x and virtual consoles

2019-08-05 Thread Ed Neville

On 2019-08-04 20:06-0400, Felix Miata wrote:

> Works on 32 bit Buster on host m7ncd here, with one little glitch that 
> Ctrl-Alt-F3

I've not tried 32bit. I'll get the ISO and give that a whirl.

> memory currently lacks any connective dots between
> https://bugzilla.redhat.com/show_bug.cgi?id=1663050
> and any possible appearance in Debian months ago.

That seems to be a different issue not vt switching from a lightdm/gdm 
spawned X to a tty spawned X crashing the login manager's X.

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-05 Thread Ed

On 2019-08-04 22:54+0100, nektarios wrote:
> Indeed the problem seems reproducible for debian Stretch with sddm 
> display manager.
> The only logs appearing are from KDE applications (nothing in X11 logs):

Could this be systemd? My only thoughts are that systemd starts the x 
server on a vt, but ctrl-alt-f6 doesn't have permission to swtich back 
to the vt. The x process has a '-novtswitch' argument which looks 
suspicious to me. I tried to change that in the lightdm conf, but it 
seems to be appended as an argument to the program (maybe hardcoded).

> Unfortunately my PC even worse gets stuck after that so I cant really 
> tell if X11 is running.
> I hadn't used multiple x sessions for sometime (after I got used to 
> multiple desktops) but this seems an issue.

I think virtualisation replaced a lot of the requirement for most people 
to have two displays running. I find user separation sufficient for most 
working-from-home tasks without needing to store a virtual disk image.

-- 
Best regards,
Ed http://www.s5h.net/

Re: x and virtual consoles

2019-08-04 Thread Felix Miata

Ed composed on 2019-08-04 21:01 (UTC+0100):

> For years I would happily ctrl-alt-f<1-6> for an additional x.org 
> session by running 'startx' and another window manager. Until now-ish.

> The way to reproduce the problem is as follows:

>   1. log in via lightdm/gdm
>   2. switch to a text console
>   3. run startx and use the window manager for a moment or two
>   4. switch back to first session

> At this point you should be presented with the default login screen 
> after the x session crashed.

> What I have observed is that x sessions started from a text console can 
> cooperate with each other, it seems limited to lightdm/gdm logins only.

> Something happened between jobs which meant I didn't need to run several 
> user accounts at once. It may have been introduced during Jessie or 
> Stretch.

> Am I alone, or do other people have this issue also? Am I doing multi 
> GUI wrong, is there a modern way to do this that has slipped past me 
> without noticing?

Works on 32 bit Buster on host m7ncd here, with one little glitch that 
Ctrl-Alt-F3
from vtty4 doesn't get me to the session running on vtty3, but Ctrl-Alt-F2 will
get me to vtty2, from which Ctrl-Alt-F3 does work as expected, as does 
Ctrl-Alt-F4
from the session on vtty3. Wierd.

However, your description I do have memory of from last winter. The problem is 
my
memory currently lacks any connective dots between
https://bugzilla.redhat.com/show_bug.cgi?id=1663050
and any possible appearance in Debian months ago.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: x and virtual consoles

2019-08-04 Thread nektarios

On Sun, 4 Aug 2019 18:36:44 -0400
Cindy Sue Causey  wrote:

> On 8/4/19, nektarios  wrote:
> > On Sun, 4 Aug 2019 21:01:57 +0100
> > Ed  wrote:  
> >>
> >> What I have observed is that x sessions started from a text console
> >> can cooperate with each other, it seems limited to lightdm/gdm
> >> logins only.
> >>
> >> Something happened between jobs which meant I didn't need to run
> >> several user accounts at once. It may have been introduced during
> >> Jessie or Stretch.
> >>
> >> Am I alone, or do other people have this issue also? Am I doing
> >> multi GUI wrong, is there a modern way to do this that has slipped
> >> past me without noticing?  
> 
> 
> After sending mine off here, I re-read and thought,, *OH, man, I fully
> missed the point.*
> 
> But I *was* able to get a GUI of *some* sort. I'm on Bullseye with
> xfce4 and ALL that it draws in.
> 
> I've never tried to get anything to interact. It's always about get
> in, un-bork something, and get back out.
> 
> Messaging between the sessions ala the way we were able to with AS/400
> systems mid-1990's comes to mind as a way to test that interaction
> ability. I've come across references to packages that MIGHT do that,
> but I've never had an excuse to download and test drive it/them.
> 
> 
> > Indeed the problem seems reproducible for debian Stretch with sddm
> > display manager.  
> 
> 
> I'll have to give it another shot with those specifics you all are
> saying, but today's definitely not that day *cognitively*. :)
> 
> I've seen where some of you all write about having even more
> minimalist systems than my bare bones debootstraps. I've tried going
> that route and just haven't found something that fits what I need.
> Might just be about adaptation and the lack of being able to do so
> under extreme duress/stress.
> 
> 
> > The only logs appearing are from KDE applications (nothing in X11
> > logs): ```
> > Aug  4 22:40:41 buldozer org.kde.kpasswdserver[958]: The X11
> > connection broke (error 1). Did the X11 server die?
> > Aug  4 22:40:41 buldozer org.kde.kuiserver[958]: kuiserver: Fatal
> > IO error: client killed
> > Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]: XIO:  fatal
> > IO error 11 (Resource temporarily unavailable) on X server ":0"
> > Aug  4 22:40:41 buldozer org.kde.kglobalaccel[958]: The X11
> > connection broke (error 1). Did the X11 server die?
> > Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]:   after
> > 947 requests (947 known processed) with 0 events remaining.
> > Aug  4 22:40:41 buldozer org.kde.KScreen[958]: The X11 connection
> > broke (error 1). Did the X11 server die?
> > ```
> >
> > Unfortunately my PC even worse gets stuck after that so I cant
> > really tell if X11 is running.
> > I hadn't used multiple x sessions for sometime (after I got used to
> > multiple desktops) but this seems an issue.  
> 
> 
> Mine referenced going to ~/.local/share/xorg/* for feedback. That's
> where I did find what appeared to be tinely appropriate for my shot at
> this.
> 
> Started to joke that I'm grateful mine at least didn't do that (get
> stuck), BUT... it DID take it n extra long while to calm down when I
> got back over to F7. That was after I successfully logged in as root
> AND "elf" (instead of "candycane") in full xfce4 graphical interface.
> 
> I'm on extremely limited hardware resources right now. 1GB RAM memory
> so I *a-sumed* that was probably what the momentary hangup was there
> when coming back up after those two success stories occurred.
> 
> I'll have to try doing more of what it sounds like you all are doing.
> I downloaded several different "window managers" (versus "desktop
> environments") just two or three weeks ago but then came back over to
> ol' familiar and friendly Xfce4. Thank you to its Developers!
> 
> I need to order a new hard drive (TODAY, yikes). With this thread in
> mind, I'll create a couple extra partitions dedicated to the "window
> managers" part of this thread when it's time.
> 
> Cindy :)



The xorg log file doesn't seem to have any kind of error in it.
At [1501.620] I start the new session but shows nothing. You can find it
attached.

Nektarios.

Xorg.1.log.old
Description: application/trash

Re: x and virtual consoles

2019-08-04 Thread Cindy Sue Causey

On 8/4/19, nektarios  wrote:
> On Sun, 4 Aug 2019 21:01:57 +0100
> Ed  wrote:
>>
>> What I have observed is that x sessions started from a text console
>> can cooperate with each other, it seems limited to lightdm/gdm logins
>> only.
>>
>> Something happened between jobs which meant I didn't need to run
>> several user accounts at once. It may have been introduced during
>> Jessie or Stretch.
>>
>> Am I alone, or do other people have this issue also? Am I doing multi
>> GUI wrong, is there a modern way to do this that has slipped past me
>> without noticing?

After sending mine off here, I re-read and thought,, *OH, man, I fully
missed the point.*

But I *was* able to get a GUI of *some* sort. I'm on Bullseye with
xfce4 and ALL that it draws in.

I've never tried to get anything to interact. It's always about get
in, un-bork something, and get back out.

Messaging between the sessions ala the way we were able to with AS/400
systems mid-1990's comes to mind as a way to test that interaction
ability. I've come across references to packages that MIGHT do that,
but I've never had an excuse to download and test drive it/them.

> Indeed the problem seems reproducible for debian Stretch with sddm display
> manager.

I'll have to give it another shot with those specifics you all are
saying, but today's definitely not that day *cognitively*. :)

I've seen where some of you all write about having even more
minimalist systems than my bare bones debootstraps. I've tried going
that route and just haven't found something that fits what I need.
Might just be about adaptation and the lack of being able to do so
under extreme duress/stress.

> The only logs appearing are from KDE applications (nothing in X11 logs):
> ```
> Aug  4 22:40:41 buldozer org.kde.kpasswdserver[958]: The X11 connection
> broke (error 1). Did the X11 server die?
> Aug  4 22:40:41 buldozer org.kde.kuiserver[958]: kuiserver: Fatal IO error:
> client killed
> Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]: XIO:  fatal IO error
> 11 (Resource temporarily unavailable) on X server ":0"
> Aug  4 22:40:41 buldozer org.kde.kglobalaccel[958]: The X11 connection broke
> (error 1). Did the X11 server die?
> Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]:   after 947
> requests (947 known processed) with 0 events remaining.
> Aug  4 22:40:41 buldozer org.kde.KScreen[958]: The X11 connection broke
> (error 1). Did the X11 server die?
> ```
>
> Unfortunately my PC even worse gets stuck after that so I cant really tell
> if X11 is running.
> I hadn't used multiple x sessions for sometime (after I got used to multiple
> desktops) but this seems an issue.

Mine referenced going to ~/.local/share/xorg/* for feedback. That's
where I did find what appeared to be tinely appropriate for my shot at
this.

Started to joke that I'm grateful mine at least didn't do that (get
stuck), BUT... it DID take it n extra long while to calm down when I
got back over to F7. That was after I successfully logged in as root
AND "elf" (instead of "candycane") in full xfce4 graphical interface.

I'm on extremely limited hardware resources right now. 1GB RAM memory
so I *a-sumed* that was probably what the momentary hangup was there
when coming back up after those two success stories occurred.

I'll have to try doing more of what it sounds like you all are doing.
I downloaded several different "window managers" (versus "desktop
environments") just two or three weeks ago but then came back over to
ol' familiar and friendly Xfce4. Thank you to its Developers!

I need to order a new hard drive (TODAY, yikes). With this thread in
mind, I'll create a couple extra partitions dedicated to the "window
managers" part of this thread when it's time.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: x and virtual consoles

2019-08-04 Thread Cindy Sue Causey

On 8/4/19, Ed  wrote:
> For years I would happily ctrl-alt-f<1-6> for an additional x.org
> session by running 'startx' and another window manager. Until now-ish.
>
> The way to reproduce the problem is as follows:
>
>   1. log in via lightdm/gdm
>   2. switch to a text console
>   3. run startx and use the window manager for a moment or two
>   4. switch back to first session
>
> At this point you should be presented with the default login screen
> after the x session crashed.
>
> What I have observed is that x sessions started from a text console can
> cooperate with each other, it seems limited to lightdm/gdm logins only.
>
> Something happened between jobs which meant I didn't need to run several
> user accounts at once. It may have been introduced during Jessie or
> Stretch.
>
> Am I alone, or do other people have this issue also? Am I doing multi
> GUI wrong, is there a modern way to do this that has slipped past me
> without noticing?

Hi, Ed.. Am not having the bestest of "cognitive" days (so the tech
aspect is just out of reach overhead), but I can comment a little. I
remember being able to have two full graphical sessions running, each
on a different [console]. I tried to do it a few months ago because of
some reason I actually needed it finally... and it didn't work.

It didn't work just now, either. It crashed again. The blurb that I
caught and that I could still remember while switching between
consoles was that it would send feedback to
~/.local/share/xorg/Xorg.1.log.

If that's true, it ends with:

"Server terminated successfully (0). Closing log file."

Successfully? Maybe it just means that it didn't hang permanently and
that it closed out without leaving any loose ends. The date stamp on
that file is appropriate for when I just tried it.

Then I got to thinking.. I next tried root and a different regular
user account, and both worked fine. Maybe I'm just remembering wrong
about past experiences.

It's possible I never tried to open two sessions of the *same* User
until very recently. If I did go that second console route for any
real purpose, it would have most likely been about accessing root for
a few seconds for whatever reason. That would explain why my memory is
that things always worked.

The first time I ever would have tried it at all would have been out
of curiosity as to whether or not two graphical interfaces were even
possible at the same time... since there ARE additional consoles just
hanging around doing nothin'. :)

Kind of make sense that it would, maybe should crash for the same
User. Seems like being signed in as the same person twice might,
likely would cause conflicts of some kind. Maybe there's a "lockfile"
situation of some type keeping the same User from signing in twice?

OR NOT. :)

Have fun!

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: x and virtual consoles

2019-08-04 Thread nektarios

On Sun, 4 Aug 2019 21:01:57 +0100
Ed  wrote:

> Hello,
> 
> For years I would happily ctrl-alt-f<1-6> for an additional x.org 
> session by running 'startx' and another window manager. Until now-ish.
> 
> The way to reproduce the problem is as follows:
> 
>   1. log in via lightdm/gdm
>   2. switch to a text console
>   3. run startx and use the window manager for a moment or two
>   4. switch back to first session
> 
> At this point you should be presented with the default login screen 
> after the x session crashed.
> 
> What I have observed is that x sessions started from a text console
> can cooperate with each other, it seems limited to lightdm/gdm logins
> only.
> 
> Something happened between jobs which meant I didn't need to run
> several user accounts at once. It may have been introduced during
> Jessie or Stretch.
> 
> Am I alone, or do other people have this issue also? Am I doing multi 
> GUI wrong, is there a modern way to do this that has slipped past me 
> without noticing?
> 

Indeed the problem seems reproducible for debian Stretch with sddm display 
manager.
The only logs appearing are from KDE applications (nothing in X11 logs):
```
Aug  4 22:40:41 buldozer org.kde.kpasswdserver[958]: The X11 connection broke 
(error 1). Did the X11 server die?
Aug  4 22:40:41 buldozer org.kde.kuiserver[958]: kuiserver: Fatal IO error: 
client killed
Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]: XIO:  fatal IO error 11 
(Resource temporarily unavailable) on X server ":0"
Aug  4 22:40:41 buldozer org.kde.kglobalaccel[958]: The X11 connection broke 
(error 1). Did the X11 server die?
Aug  4 22:40:41 buldozer org.a11y.atspi.Registry[1251]:   after 947 
requests (947 known processed) with 0 events remaining.
Aug  4 22:40:41 buldozer org.kde.KScreen[958]: The X11 connection broke (error 
1). Did the X11 server die?
```

Unfortunately my PC even worse gets stuck after that so I cant really tell if 
X11 is running.
I hadn't used multiple x sessions for sometime (after I got used to multiple 
desktops) but this seems an issue.

x and virtual consoles

2019-08-04 Thread Ed

Hello,

For years I would happily ctrl-alt-f<1-6> for an additional x.org 
session by running 'startx' and another window manager. Until now-ish.

The way to reproduce the problem is as follows:

  1. log in via lightdm/gdm
  2. switch to a text console
  3. run startx and use the window manager for a moment or two
  4. switch back to first session

At this point you should be presented with the default login screen 
after the x session crashed.

What I have observed is that x sessions started from a text console can 
cooperate with each other, it seems limited to lightdm/gdm logins only.

Something happened between jobs which meant I didn't need to run several 
user accounts at once. It may have been introduced during Jessie or 
Stretch.

Am I alone, or do other people have this issue also? Am I doing multi 
GUI wrong, is there a modern way to do this that has slipped past me 
without noticing?

-- 
Best regards,
Ed http://www.s5h.net/

Re: [solved] Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Rodolfo Medina

Greg Wooledge <wool...@eeg.ccf.org> writes:

> On Tue, Jun 20, 2017 at 05:32:09PM +0100, Rodolfo Medina wrote:
>> Greg Wooledge <wool...@eeg.ccf.org> writes:
>> > Once more, from the top:
>> >
>> > 1) ~/.bash_profile should source ~/.bashrc
>> > 2) Shell functions and aliases and shopts and sets and other transient
>> >settings should go in ~/.bashrc
>> > 3) Environment variables and other NON-transient settings should go in
>> >~/.bash_profile
>
>> My alias:
>> 
>>  alias mplayer='mplayer -demuxer lavf'
>> 
>> works, for tty* consoles, if I put it in ~/.bash_profile.  Instead, if I put
>> it in ~/.bashrc, it doesn't work within tty* but only within graphical
>> system.
>
> Refer to step 1.  Make sure ~/.bash_profile sources ~/.bashrc.
>
> Debian provides a ~/.profile by default in jessie and stretch, so
> ~/.bash_profile is either something you wrote, or something you
> inherited from an older system.
>
> Make ~/.bash_profile source ~/.bashrc.
>
> If you need help with that, you can paste the code from /etc/skel/.profile
> starting with "# if running bash" and ending with the second "fi" line
> which follows that comment.
>
> ~/.bash_profile must source ~/.bashrc


Sorry, at the beginning I hadn't given enough importance to your recommendation
that ~/.bash_profile should source ~/.bashrc.  Now I put my alias in ~/bashrc,
then at the beginning of ~/.bash_profile I put:

# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi

and everything is fine: the alias is also active in tty* consoles.  I hope now
I understood and did correctly.

Thanks, Regards

Rodolfo

Re: [solved] Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Greg Wooledge

On Tue, Jun 20, 2017 at 05:32:09PM +0100, Rodolfo Medina wrote:
> Greg Wooledge <wool...@eeg.ccf.org> writes:
> > Once more, from the top:
> >
> > 1) ~/.bash_profile should source ~/.bashrc
> > 2) Shell functions and aliases and shopts and sets and other transient
> >settings should go in ~/.bashrc
> > 3) Environment variables and other NON-transient settings should go in
> >~/.bash_profile

> My alias:
> 
>  alias mplayer='mplayer -demuxer lavf'
> 
> works, for tty* consoles, if I put it in ~/.bash_profile.  Instead, if I put 
> it
> in ~/.bashrc, it doesn't work within tty* but only within graphical system.

Refer to step 1.  Make sure ~/.bash_profile sources ~/.bashrc.

Debian provides a ~/.profile by default in jessie and stretch, so
~/.bash_profile is either something you wrote, or something you
inherited from an older system.

Make ~/.bash_profile source ~/.bashrc.

If you need help with that, you can paste the code from /etc/skel/.profile
starting with "# if running bash" and ending with the second "fi" line
which follows that comment.

~/.bash_profile must source ~/.bashrc

Re: [solved] Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Rodolfo Medina

Greg Wooledge <wool...@eeg.ccf.org> writes:

> On Tue, Jun 20, 2017 at 04:43:25PM +0100, Rodolfo Medina wrote:
>> According to what you say, I solved my problem by putting my aliases in
>> ~/.bash_profile rather than in ~/.bash_aliases.  I don't know if it's
>> correct, but it works.
>
> It's not correct, because that file WON'T be read by regular shells.
> It's only read by login shells.
>
> Once more, from the top:
>
> 1) ~/.bash_profile should source ~/.bashrc
> 2) Shell functions and aliases and shopts and sets and other transient
>settings should go in ~/.bashrc
> 3) Environment variables and other NON-transient settings should go in
>~/.bash_profile
>
> Substitute ~/.profile for ~/.bash_profile if necessary.  This is the file
> that is only read once.
>
> Substitute ~/.bash_aliases for ~/.bashrc if necessary.  This is the file
> that is read by every new instance of the shell.


My alias:

 alias mplayer='mplayer -demuxer lavf'

works, for tty* consoles, if I put it in ~/.bash_profile.  Instead, if I put it
in ~/.bashrc, it doesn't work within tty* but only within graphical system.

Rodolfo

Re: [solved] Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Greg Wooledge

On Tue, Jun 20, 2017 at 04:43:25PM +0100, Rodolfo Medina wrote:
> According to what you say, I solved my problem by putting my aliases in
> ~/.bash_profile rather than in ~/.bash_aliases.  I don't know if it's correct,
> but it works.

It's not correct, because that file WON'T be read by regular shells.
It's only read by login shells.

Once more, from the top:

1) ~/.bash_profile should source ~/.bashrc
2) Shell functions and aliases and shopts and sets and other transient
   settings should go in ~/.bashrc
3) Environment variables and other NON-transient settings should go in
   ~/.bash_profile

Substitute ~/.profile for ~/.bash_profile if necessary.  This is the file
that is only read once.

Substitute ~/.bash_aliases for ~/.bashrc if necessary.  This is the file
that is read by every new instance of the shell.

[solved] Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Rodolfo Medina

Greg Wooledge  writes:

> On Tue, Jun 20, 2017 at 04:06:24PM +0100, Rodolfo Medina wrote:
>> I settle down permamnent bash aliases by simply putting them in the file
>> ~/.bash_aliases; but they only work within X environment.  Is it possible,
>> and how?, to make them work also in tty1, tty2, ..., i.e. out of graphical
>> surround?
>
> Shell aliases and functions should be declared in ~/.bashrc or in a file
> that you source from ~/.bashrc.  Some people like to create a ~/.bash_aliases
> and source that from ~/.bashrc -- that's fine.  Sounds like you are doing
> that.
>
> The other step is that you need to ensure ~/.bashrc gets sourced from
> your login profile, so that it gets picked up by ALL interactive shells
> (login and non-login).  If you have a ~/.bash_profile or ~/.bash_login,
> make sure you source ~/.bashrc from there.  Otherwise, if you don't
> have those, make sure you source it from ~/.profile.
>
> When you login on a text console, you get a login shell, which reads
> ~/.bash_profile or ~/.bash_login or ~/.profile but not ~/.bashrc.
> (Which is why you need that extra source step.)
>
> When you run a terminal emulator within an X session, you *typically*
> get a non-login shell, which reads ~/.bashrc only.


According to what you say, I solved my problem by putting my aliases in
~/.bash_profile rather than in ~/.bash_aliases.  I don't know if it's correct,
but it works.

Thanks,

Rodolfo

Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Greg Wooledge

On Tue, Jun 20, 2017 at 11:36:17AM -0400, Felix Miata wrote:
> Greg Wooledge composed on 2017-06-20 11:14 (UTC-0400):
> > When you run a terminal emulator within an X session, you *typically*
> > get a non-login shell, which reads ~/.bashrc only.
> .
> Interesting. Which WM(s)/DE(s) do/does that apply to?

Depends on the config, and the terminal emulator as well.  A standard
WM menu should simply run the terminal emulator (e.g. urxvt) with
no options, which will then run a regular (non-login) shell.

However, some people configure their WMs to launch their terminals with
the "-ls" or equivalent option, which forces a login shell.  This is
common in academic environments, for example.  I think the rationale is
that it makes life simpler for non-sophisticated users, who will just
put their aliases in whatever dot file they happen to stumble across;
forcing a login shell means *all* the dot files get read, so they get
fewer support calls.

Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Felix Miata

Greg Wooledge composed on 2017-06-20 11:14 (UTC-0400):

> When you login on a text console, you get a login shell, which reads
> ~/.bash_profile or ~/.bash_login or ~/.profile but not ~/.bashrc.
> (Which is why you need that extra source step.)

> When you run a terminal emulator within an X session, you *typically*
> get a non-login shell, which reads ~/.bashrc only.
.
Interesting. Which WM(s)/DE(s) do/does that apply to? 'alias | wc -l' produces
same result here whether in vtty or in Konsole, whether root (53) or ordinary
user (22), my self-created aliases are all in ~/.bashrc, and except for
(non-existent) /etc/bashrc I have no reference to any other startup or other
script in ~/.bashrc.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Greg Wooledge

On Tue, Jun 20, 2017 at 04:06:24PM +0100, Rodolfo Medina wrote:
> I settle down permamnent bash aliases by simply putting them in the file
> ~/.bash_aliases; but they only work within X environment.  Is it possible, and
> how?, to make them work also in tty1, tty2, ..., i.e. out of graphical
> surround?

Shell aliases and functions should be declared in ~/.bashrc or in a file
that you source from ~/.bashrc.  Some people like to create a ~/.bash_aliases
and source that from ~/.bashrc -- that's fine.  Sounds like you are doing
that.

The other step is that you need to ensure ~/.bashrc gets sourced from
your login profile, so that it gets picked up by ALL interactive shells
(login and non-login).  If you have a ~/.bash_profile or ~/.bash_login,
make sure you source ~/.bashrc from there.  Otherwise, if you don't
have those, make sure you source it from ~/.profile.

When you login on a text console, you get a login shell, which reads
~/.bash_profile or ~/.bash_login or ~/.profile but not ~/.bashrc.
(Which is why you need that extra source step.)

When you run a terminal emulator within an X session, you *typically*
get a non-login shell, which reads ~/.bashrc only.

Setting up aliases to work also in tty* consoles?

2017-06-20 Thread Rodolfo Medina

Hi all.

I settle down permamnent bash aliases by simply putting them in the file
~/.bash_aliases; but they only work within X environment.  Is it possible, and
how?, to make them work also in tty1, tty2, ..., i.e. out of graphical
surround?

Thanks for any help,

Rodolfo

Re: only one user with access to vt consoles in multiseat set ups ...

2016-08-04 Thread Albretch Mueller

 Also, something important to me is for each seat to be able to go
into init 5 under its own locale

 Say, one seat would be running under a French locale and the other
one a German one.

 lbrtchx

only one user with access to vt consoles in multiseat set ups ...

2016-08-04 Thread Albretch Mueller

 I would like to know the reason for the following note:
~
 https://wiki.debian.org/Multi_Seat_Debian_HOWTO

 NOTE: Only the user on the first monitor has the use of vt consoles
and can use Ctrl+Alt+F to select them. The other users have a gdm
login screen and can use X normally, but have no vt's.
~
 I teach java and at times I need for my students to have access to the console

 Is this because of the graphical interface being used? Kernel config issues?

 lbrtchx
 debian-user

Re: What's with the blue overlining in text consoles?

2013-07-16 Thread Chris Bannister


[Please don't top post on this mailing list]

On Sun, Jul 14, 2013 at 05:10:18PM +0200, commandline wrote:
 Never heard of something similar to start with. Few guesses.
 
 * Terminal Emulation ?
   Check what happens if you switch from say xterm to linux to vt100 to ...

Stephen did say when used in a text console (vt1-vt6) and 
The problem does not seem to occur in a Gnome Terminal window, only 
on a text console.

 I'd suggest you make a backup of the current files, then proceed

Which files in particular?

 with tests. If it still fails proceed to reinstall the packages.

Which tests are you suggesting? And why would you need to reinstall the
packages?


-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716072146.GB17167@tal

What's with the blue overlining in text consoles? [SOLVED]

2013-07-15 Thread Stephen Powell

On Sun, 14 Jul 2013 11:10:18 -0400 (EDT), commandl...@telenet.be wrote:
 
 On 13/07/13 21:55, Stephen Powell wrote:
 
 Something strange has started happening recently.  For a long time I have
 used ISO-8859-1 as my character mapping in text consoles.

 dpkg-reconfigure console-setup

 and I have had no difficulty, except when using the ssh client to connect
 to a remote system which uses UTF-8.  The box-drawing characters sent by
 the remote system did not look right under these conditions.  To solve this
 problem, I switched my local system to use UTF-8.  Now the box-drawing
 characters sent by the remote system look right when displayed by my
 local ssh client.  However, I recently began noticing that all blue fields
 are now overlined.  For example, the lynx web browser, when used in a
 text console (vt1-vt6), displays emphasized fields (the em.../em html
 tag) as blue overlined, when it used to display them simply as blue.

 I can live with that, I suppose.  But what really bothers me is when I
 use the c3270 text-mode 3270 terminal emulator to logon to a mainframe.
 All blue fields are now overlined!  This is driving me batty!  I tried
 searching the world wide web using search words of

 blue overlining UTF-8

 but did not obtain any useful results.  Does anyone know the cause of this?
 Does anyone know the cure?  Is this a bug?  If so, in what package is the
 bug?  The problem does not seem to occur in a Gnome Terminal window, only
 on a text console.  My system locale is en_US.UTF-8.  I am running an
 up-to-date Jessie system on i386 architecture.
 
 Never heard of something similar to start with.  Few guesses.
 
 * Terminal Emulation?
   Check what happens if you switch from say xterm to linux to vt100 to ...
 
 * Character map error?
   Might be for some reason the charmap is damaged?  Did you edit them at 
 one point?  Of would someone else have access to them?
 
 I'd suggest you make a backup of the current files, then proceed with 
 tests.  If it still fails proceed to reinstall the packages. Then check 
 again...
 
 Do you mix the repo with Wheezy or unstable?  This might at times cause 
 quite unique weirdness.

Thank you for your reply, but please don't top post.  I took the liberty of
reformatting this post in the bottom posting / interleaving style.

Well, after a lot of trial-and-error experimentation, I have found the culprit.
It's the video BIOS.  This video BIOS supports eleven hardware text modes,
as documented below:

hex mode id screen size   character cell
(vga=ask)   (text columns x   size (horiz pixels
text rows)x vert pixels)

F00 80x25 9x16
F01 80x50 9x8
F02 80x43 8x8
F03 80x28 9x14
F05 80x30 9x16
F06 80x34 9x14
F07 80x60 9x8
121 100x259x16
122 100x309x16
123 132x258x16
133 132x448x8

Of these eleven hardware text video modes, ten of them work fine.  That is, blue
fields appear without overlining.  One of them is defective.  Mode id 0x122,
for 100 text columns by 30 text rows, displays blue fields with overlining.
And that's the one I was using.  Coincidentally, I switched from 80x34 to
100x30 shortly after I switched from ISO-8859-1 character mapping to UTF-8
character mapping.  The overlining of blue fields had nothing to do with the
switch to UTF-8.  It just appeared to be related because the video mode switch
occurred at about the same time.  The video BIOS apparently does not set up
the VGA registers correctly for video mode id 0x122.  But it does for all the
other text video modes.  The solution (actually a circumvention) is to choose
a different video mode.  Problem solved.  For those of you who are interested,
here is the information I have been able to obtain about my video chipset
and BIOS:

The video chipset is listed by lspci -nn as follows:

05:03.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Rage XL PCI [1002:4752] (rev 27)

The video chip is built-in to the motherboard; so it's video BIOS is built-in 
to the
motherboard too.

/var/log/Xorg.0.log shows the following information about the video BIOS:

MACH64(0): Primary V_BIOS segment is: 0xc000
...
MACH64(0): VESA BIOS detected
MACH64(0): VESA VBE Version 2.0
MACH64(0): VESA VBE Total Mem: 8128 kB
MACH64(0): VESA VBE OEM: ATI MACH64
MACH64(0): VESA VBE OEM Software Rev: 1.0
MACH64(0): VESA VBE OEM Vendor: ATI Technologies Inc.
MACH64(0): VESA VBE OEM Product: MACH64GM
MACH64(0): VESA VBE OEM Product Rev: 01.00

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive

Re: What's with the blue overlining in text consoles?

2013-07-14 Thread commandline


Never heard of something similar to start with. Few guesses.

* Terminal Emulation ?
Check what happens if you switch from say xterm to linux to vt100 to ...

* Character map error ?
	Might be for some reason the charmap is damaged ? Did you edit them at 
one point ? Of would someone else have access to them ?


I'd suggest you make a backup of the current files, then proceed with 
tests. If it still fails proceed to reinstall the packages. Then check 
again...


Do you mix the repo with Wheezy or unstable ? This might at times cause 
quite unique weirdness.




On 13/07/13 21:55, Stephen Powell wrote:

Something strange has started happening recently.  For a long time I have
used ISO-8859-1 as my character mapping in text consoles.

dpkg-reconfigure console-setup

and I have had no difficulty, except when using the ssh client to connect
to a remote system which uses UTF-8.  The box-drawing characters sent by
the remote system did not look right under these conditions.  To solve this
problem, I switched my local system to use UTF-8.  Now the box-drawing
characters sent by the remote system look right when displayed by my
local ssh client.  However, I recently began noticing that all blue fields
are now overlined.  For example, the lynx web browser, when used in a
text console (vt1-vt6), displays emphasized fields (the em.../em html
tag) as blue overlined, when it used to display them simply as blue.

I can live with that, I suppose.  But what really bothers me is when I
use the c3270 text-mode 3270 terminal emulator to logon to a mainframe.
All blue fields are now overlined!  This is driving me batty!  I tried
searching the world wide web using search words of

blue overlining UTF-8

but did not obtain any useful results.  Does anyone know the cause of this?
Does anyone know the cure?  Is this a bug?  If so, in what package is the
bug?  The problem does not seem to occur in a Gnome Terminal window, only
on a text console.  My system locale is en_US.UTF-8.  I am running an
up-to-date Jessie system on i386 architecture.




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/51e2bf5a.2080...@telenet.be

What's with the blue overlining in text consoles?

2013-07-13 Thread Stephen Powell

Something strange has started happening recently. For a long time I have
used ISO-8859-1 as my character mapping in text consoles.

dpkg-reconfigure console-setup

and I have had no difficulty, except when using the ssh client to connect
to a remote system which uses UTF-8. The box-drawing characters sent by
the remote system did not look right under these conditions. To solve this
problem, I switched my local system to use UTF-8. Now the box-drawing
characters sent by the remote system look right when displayed by my
local ssh client. However, I recently began noticing that all blue fields
are now overlined. For example, the lynx web browser, when used in a
text console (vt1-vt6), displays emphasized fields (the em.../em html
tag) as blue overlined, when it used to display them simply as blue.

I can live with that, I suppose. But what really bothers me is when I
use the c3270 text-mode 3270 terminal emulator to logon to a mainframe.
All blue fields are now overlined! This is driving me batty! I tried
searching the world wide web using search words of

blue overlining UTF-8

but did not obtain any useful results. Does anyone know the cause of this?
Does anyone know the cure? Is this a bug? If so, in what package is the
bug? The problem does not seem to occur in a Gnome Terminal window, only
on a text console. My system locale is en_US.UTF-8. I am running an
up-to-date Jessie system on i386 architecture.

--
.''`. Stephen Powell
: :' :
`. `'`
`-

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1182082504.2151649.1373745348517.javamail.r...@md01.wow.synacor.com

1 2 3 4 5 >

1 - 100 of 477 matches

Mail list logo