Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Mark Knecht wrote:
>
>
> On Tue, Jul 2, 2024 at 12:44 PM Dale  > wrote:
> 
> > I tried it with those options and without.  Neither changed anything.  I
> > originally tried it with no xorg.conf at all.  I was hoping maybe the
> > Nvidia GUI thing would adjust things.  I may try that again.  No
> > xorg.conf and use the GUI thing.  That's what I use to set up my TV and
> > such anyway.  Thing is, the sddm screen is HUGE too.
> 
> > :-)  :-)
>
> ???
>
> xdpyinfo | grep -B2 resolution
>
> ???


I booted my new rig up again.  Dang that thing.  It was HUGE again.  I
started reading stuff, mainly about xorg.conf and the available
settings.  I changed all sorts of stuff, including some things Micheal
suggested.  I restarted DM each time.  I was about ready to toss it in
the old minnow pond, that's where everything goes to die here.  Lots of
CRT monitors in there.  LOL  Anyway, I had to install that package to
run that command.  It spit out a oops when I tried to run it after a
copy and paste.  I also installed it on my main rig, just to compare. 
On the new rig, the DPI was a fairly large number.  I thought I had the
output saved but it seems to be gone.  My main rig tho showed 80x80 dots
per inch.  I did a duck search, finally found how to set that.  I then
restarted DM and YEPPIE!!!  It was a normal size again. 

Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
years???  Should newer monitors be set to a higher number for DPI?  Is
that normal?  Why was it using such a high number by default?  I want to
say one was like 200 or something.  It was quite large.  The reason I'm
asking, I may need to set something else to make the screen the right
size but let it use that larger dpi number, if that is what the newer
monitor prefers to use. 

Now to reboot, see if I have thoughts of that minnow pond again.  :/ 

Dale

:-)  :-) 

P. S.  Funny story.  I picked basil again today.  I wash it in cold
water with salt mixed in.  The salt acts like a detergent but without a
nasty taste and easy to rinse off.  Anyway, ran out of salt.  I have
large ammo cans that I store stuff in that I want to keep dry, with some
silica packs to help keep it dry.  Anyway, I started looking for the can
with salt wrote on a post it note stuck to it.  I looked everywhere I
could think of.  Finally, I came to my room and took a break.  Then I
noticed what the new rig was sitting on.  The ammo can with salt wrote
on a post it note stuck to it.  That case was pretty heavy empty but it
is really heavy now with the extra stuff in it.  Anyway, after unhooking
everything, moving the monitor out of the way and all, I got some more
salt.  Given the problems I'm having, I took out two things of salt, in
case it takes a while to beat the new rig into submission. 

Oh, I got a LOT of basil now.  Should last me several years.  I've had
to move to larger jars twice now.  I had almost another ice cream bucket
full which was 5 trays worth in my dehydrator.  O_O 

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Michael]

On Saturday, 6 July 2024 10:59:30 BST Dale wrote:
> Mark Knecht wrote:
> > On Tue, Jul 2, 2024 at 12:44 PM Dale  > > wrote:
> > 
> > 
> > > I tried it with those options and without.  Neither changed anything.  I
> > > originally tried it with no xorg.conf at all.  I was hoping maybe the
> > > Nvidia GUI thing would adjust things.  I may try that again.  No
> > > xorg.conf and use the GUI thing.  That's what I use to set up my TV and
> > > such anyway.  Thing is, the sddm screen is HUGE too.
> > 
> > 
> > 
> > > :-)  :-)
> > 
> > ???
> > 
> > xdpyinfo | grep -B2 resolution
> > 
> > ???
> 
> I booted my new rig up again.  Dang that thing.  It was HUGE again.  I
> started reading stuff, mainly about xorg.conf and the available
> settings.  I changed all sorts of stuff, including some things Micheal
> suggested.  I restarted DM each time.  I was about ready to toss it in
> the old minnow pond, that's where everything goes to die here.  Lots of
> CRT monitors in there.  LOL  Anyway, I had to install that package to
> run that command.  It spit out a oops when I tried to run it after a
> copy and paste.  I also installed it on my main rig, just to compare. 
> On the new rig, the DPI was a fairly large number.  I thought I had the
> output saved but it seems to be gone.  My main rig tho showed 80x80 dots
> per inch.  I did a duck search, finally found how to set that.  I then
> restarted DM and YEPPIE!!!  It was a normal size again. 
> 
> Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
> years???  Should newer monitors be set to a higher number for DPI?  Is
> that normal?  Why was it using such a high number by default?  I want to
> say one was like 200 or something.  It was quite large.  The reason I'm
> asking, I may need to set something else to make the screen the right
> size but let it use that larger dpi number, if that is what the newer
> monitor prefers to use. 
> 
> Now to reboot, see if I have thoughts of that minnow pond again.  :/ 
> 
> Dale
> 
> :-)  :-) 

I'm struggling to follow your post because you do not provide specific 
information on the commands you input, the output you get in your terminal and 
the observed changes in the monitor.

You also don't provide info on the changes you made in your xorg.conf, or 
xrandr and the corresponding changes observed each time in your Xorg.0.log.

Strictly speaking, the pixel density of an on-screen digital image is referred 
to as Pixels Per Inch (PPI), but the term DPI which refers to a printed image 
of ink Dots Per Inch has stuck.

In addition, there is the physical pixel density of your monitor and the 
rendered pixel density of the X11 image(s).  Tweaking the latter allows you to 
scale the display and make images look larger than the native monitor 
resolution.

You can set the DPI in your xorg.conf, or you can set it with xranrd, or you 
can set it on the CLI when you launch X, but usually this is not necessary and 
could mess up the scaling of your fonts, window decorations and symbols too 
(the font DPI is set differently by setting Xft.dpi: in ~/.Xresources, of the 
window manager's/DE font settings).

A good starting point is to get the manual of your monitor and look at its 
published native resolution, e.g. 1920x1080 and the physical monitor size over 
which this resolution is displayed.  Let's assume this 1920x1080 native 
resolution belongs to a 23" monitor.  A 23" diagonal would correspond to a 20" 
wide screen real estate.  Consequently the horizontal PPI would be:

PPI = 1920 pixels / 20" = 96

The same resolution on a 24" wide monitor would give a PPI of:

PPI = 1920 pixels / 24" = 80

Obviously a physically wider 24" monitor with the same native screen 
resolution as a smaller 20" monitor will not look as sharp when viewed from 
the *same* distance.

Similarly, changing the selected resolution on the same 23" monitor from say 
1920 pixels wide to a lower resolution of 1280 pixels gives a PPI of 64.

I leave the calculation of the vertical PPI to the reader.

Usually I start with no xorg.conf and leave the card to detect what the 
monitor prefers, then use the Scale setting in the desktop settings to 
increase/decrease (zoom in/zoom out) the displayed scale.  This has the effect 
of altering the PPI to higher or lower values to improve readability of 
content.  The above should help you arrive at some practical resolution, but I 
would start with the native resolution of the monitor and work down from there 
if you find it difficult to read its display.

NOTE: Using Qt scaling can mess up window decorations, widgets, etc.  I've 
found it doesn't work well with some KDE applications and their menus/
submenus, or pop up windows.  You need to set PLASMA_USE_QT_SCALING=1 to make 
it follow Qt scaling and there's GTK3 too which may need tuning.  This is the 
reason I calculate PPI before I venture into buying a new monitor, unless I 
can see it in person to make sure I can still read its conten

[gentoo-user] New bashrc

[Peter Humphrey]

Hello list,

Would someone please either post the new bashrc file here or send me a copy, 
in which genfun_has_readline is defined? I seem to have lost mine altogether. I 
think portage may be being too clever in remembering config files that I've not 
allowed it to update previously, and so not offering to update it now.

I mean app-shells/bash-5.2_p26-r6.

Many thanks.

-- 
Regards,
Peter.

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Michael wrote:
> On Saturday, 6 July 2024 10:59:30 BST Dale wrote:
>> Mark Knecht wrote:
>>> On Tue, Jul 2, 2024 at 12:44 PM Dale >> > wrote:
>>> 
>>>
 I tried it with those options and without.  Neither changed anything.  I
 originally tried it with no xorg.conf at all.  I was hoping maybe the
 Nvidia GUI thing would adjust things.  I may try that again.  No
 xorg.conf and use the GUI thing.  That's what I use to set up my TV and
 such anyway.  Thing is, the sddm screen is HUGE too.
>>> 
>>>
 :-)  :-)
>>> ???
>>>
>>> xdpyinfo | grep -B2 resolution
>>>
>>> ???
>> I booted my new rig up again.  Dang that thing.  It was HUGE again.  I
>> started reading stuff, mainly about xorg.conf and the available
>> settings.  I changed all sorts of stuff, including some things Micheal
>> suggested.  I restarted DM each time.  I was about ready to toss it in
>> the old minnow pond, that's where everything goes to die here.  Lots of
>> CRT monitors in there.  LOL  Anyway, I had to install that package to
>> run that command.  It spit out a oops when I tried to run it after a
>> copy and paste.  I also installed it on my main rig, just to compare. 
>> On the new rig, the DPI was a fairly large number.  I thought I had the
>> output saved but it seems to be gone.  My main rig tho showed 80x80 dots
>> per inch.  I did a duck search, finally found how to set that.  I then
>> restarted DM and YEPPIE!!!  It was a normal size again. 
>>
>> Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
>> years???  Should newer monitors be set to a higher number for DPI?  Is
>> that normal?  Why was it using such a high number by default?  I want to
>> say one was like 200 or something.  It was quite large.  The reason I'm
>> asking, I may need to set something else to make the screen the right
>> size but let it use that larger dpi number, if that is what the newer
>> monitor prefers to use. 
>>
>> Now to reboot, see if I have thoughts of that minnow pond again.  :/ 
>>
>> Dale
>>
>> :-)  :-) 
> I'm struggling to follow your post because you do not provide specific 
> information on the commands you input, the output you get in your terminal 
> and 
> the observed changes in the monitor.
>
> You also don't provide info on the changes you made in your xorg.conf, or 
> xrandr and the corresponding changes observed each time in your Xorg.0.log.
>
> Strictly speaking, the pixel density of an on-screen digital image is 
> referred 
> to as Pixels Per Inch (PPI), but the term DPI which refers to a printed image 
> of ink Dots Per Inch has stuck.
>
> In addition, there is the physical pixel density of your monitor and the 
> rendered pixel density of the X11 image(s).  Tweaking the latter allows you 
> to 
> scale the display and make images look larger than the native monitor 
> resolution.
>
> You can set the DPI in your xorg.conf, or you can set it with xranrd, or you 
> can set it on the CLI when you launch X, but usually this is not necessary 
> and 
> could mess up the scaling of your fonts, window decorations and symbols too 
> (the font DPI is set differently by setting Xft.dpi: in ~/.Xresources, of the 
> window manager's/DE font settings).
>
> A good starting point is to get the manual of your monitor and look at its 
> published native resolution, e.g. 1920x1080 and the physical monitor size 
> over 
> which this resolution is displayed.  Let's assume this 1920x1080 native 
> resolution belongs to a 23" monitor.  A 23" diagonal would correspond to a 
> 20" 
> wide screen real estate.  Consequently the horizontal PPI would be:
>
> PPI = 1920 pixels / 20" = 96
>
> The same resolution on a 24" wide monitor would give a PPI of:
>
> PPI = 1920 pixels / 24" = 80
>
> Obviously a physically wider 24" monitor with the same native screen 
> resolution as a smaller 20" monitor will not look as sharp when viewed from 
> the *same* distance.
>
> Similarly, changing the selected resolution on the same 23" monitor from say 
> 1920 pixels wide to a lower resolution of 1280 pixels gives a PPI of 64.
>
> I leave the calculation of the vertical PPI to the reader.
>
> Usually I start with no xorg.conf and leave the card to detect what the 
> monitor prefers, then use the Scale setting in the desktop settings to 
> increase/decrease (zoom in/zoom out) the displayed scale.  This has the 
> effect 
> of altering the PPI to higher or lower values to improve readability of 
> content.  The above should help you arrive at some practical resolution, but 
> I 
> would start with the native resolution of the monitor and work down from 
> there 
> if you find it difficult to read its display.
>
> NOTE: Using Qt scaling can mess up window decorations, widgets, etc.  I've 
> found it doesn't work well with some KDE applications and their menus/
> submenus, or pop up windows.  You need to set PLASMA_USE_QT_SCALING=1 to make 
> it follow Qt scaling and there's GTK3 too which may need tuning.  This is the

Re: [gentoo-user] New bashrc

[Dale]

Peter Humphrey wrote:
> Hello list,
>
> Would someone please either post the new bashrc file here or send me a copy, 
> in which genfun_has_readline is defined? I seem to have lost mine altogether. 
> I 
> think portage may be being too clever in remembering config files that I've 
> not 
> allowed it to update previously, and so not offering to update it now.
>
> I mean app-shells/bash-5.2_p26-r6.
>
> Many thanks.
>


I think this gives the new config files.  I save the binaries that
emerge creates.  I found the new bash and extracted the config files. 
The ones that start with a number are in the bashrc.d directory.  They
are attached. 

I might add, after the update, I had issues with my PS1 and alias
settings.  My main rig went rather well given it has been through a few
updates.  The new rig however was like pulling teeth.  I ended up
copying the /etc/bash directory from my main rig.  Then it worked. 
Using dispatch-conf and me rarely being able to use it correctly is
causing problems.  I need to find a better tool.  Thing is, I don't
think one exists.  I'd encourage you to use the bashrc.d directory when
possible.  That way your settings aren't mixed in with defaults. 

Hope those files help. 

Dale

:-)  :-) 
# /etc/bash/bashrc.d/10-gentoo-color.bash

if [[ ${NO_COLOR} ]]; then
# Respect the user's wish not to use color. See https://no-color.org/.
gentoo_color=0
elif [[ ${COLORTERM@a} == *x* && ${COLORTERM} == @(24bit|truecolor) ]]; then
# The COLORTERM environment variable can reasonably be trusted here.
# See https://github.com/termstandard/colors for further information.
gentoo_color=1
elif unset -v COLORTERM; ! gentoo_color=$(tput colors 2>/dev/null); then
# Either ncurses is not installed or no terminfo database could be
# found. Fall back to a whitelist which covers the majority of terminal
# emulators and virtual console implementations known to support color
# and which remain (somewhat) popular. This will rarely happen, so the
# list need not be exhaustive.
case ${TERM} in
*color*|\
*direct*   |\
[Ekx]term* |\
alacritty  |\
aterm  |\
dtterm |\
foot*  |\
jfbterm|\
linux  |\
mlterm |\
rxvt*  |\
screen*|\
tmux*  |\
wsvt25*) gentoo_color=1
esac
elif (( gentoo_color == 16777216 )); then
# Truecolor support is available. Advertise it.
export COLORTERM=truecolor
fi

# For direxpand to be missing indicates that bash is lacking readline support.
if (( gentoo_color <= 0 )) || [[ ! $(shopt -p direxpand 2>/dev/null) ]]; then
# Define a prompt without color.
PS1='\u@\h \w \$ '
elif (( EUID == 0 )); then
# If root, omit the username and print the hostname in red.
PS1='\[\e[01;31m\]\h\[\e[01;34m\] \w \$\[\e[00m\] '
else
# Otherwise, print the username and hostname in green.
PS1='\[\e[01;32m\]\u@\h\[\e[01;34m\] \w \$\[\e[00m\] '
fi

if (( gentoo_color > 0 )); then
# Colorize the output of diff(1), grep(1) and a few coreutils utilities.
for _ in diff dir grep ls vdir; do
alias "$_=$_ --color=auto"
done

# Enable colors for ls(1) and some other utilities that respect the
# LS_COLORS variable. Prefer ~/.dir_colors, per bug #64489.
if hash dircolors 2>/dev/null; then
if [[ -f ~/.dir_colors ]]; then
eval "$(dircolors -b -- ~/.dir_colors)"
elif [[ -f /etc/DIR_COLORS ]]; then
eval "$(dircolors -b /etc/DIR_COLORS)"
else
eval "$(dircolors -b)"
fi
fi
fi

unset -v gentoo_color
# /etc/bash/bashrc.d/10-gentoo-title.bash

genfun_set_win_title() {
# Assigns the basename of the current working directory, having
# sanitised it with @Q parameter expansion. Useful for paths containing
# newlines and such. As a special case, names consisting entirely of
# graphemes shall not undergo the expansion, for reasons of cleanliness.
genfun_sanitise_cwd() {
_cwd=${PWD##*/}
if [[ ! ${_cwd} ]]; then
_cwd=${PWD}
elif [[ ${_cwd} == *[![:graph:]]* ]]; then
_cwd=${_cwd@Q}
fi
}

# Sets the window title with the Set Text Parameters sequence. For
# screen, the sequence defines the hardstatus (%h) and for tmux, the
# pane_title (#T). For graphical terminal emulators, it is normal for
# the title bar to be affected.
genfun_set_win_title() {
genfun_sanitise_cwd
printf '\033]2;%s@%s - %s\007' "${

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Michael]

On Saturday, 6 July 2024 17:11:23 BST Dale wrote:
> Michael wrote:
> > On Saturday, 6 July 2024 10:59:30 BST Dale wrote:
> >> Mark Knecht wrote:
> >>> On Tue, Jul 2, 2024 at 12:44 PM Dale  >>> > wrote:
> >>> 
> >>> 
>  I tried it with those options and without.  Neither changed anything. 
>  I
>  originally tried it with no xorg.conf at all.  I was hoping maybe the
>  Nvidia GUI thing would adjust things.  I may try that again.  No
>  xorg.conf and use the GUI thing.  That's what I use to set up my TV and
>  such anyway.  Thing is, the sddm screen is HUGE too.
> >>> 
> >>> 
> >>> 
>  :-)  :-)
> >>> 
> >>> ???
> >>> 
> >>> xdpyinfo | grep -B2 resolution
> >>> 
> >>> ???
> >> 
> >> I booted my new rig up again.  Dang that thing.  It was HUGE again.  I
> >> started reading stuff, mainly about xorg.conf and the available
> >> settings.  I changed all sorts of stuff, including some things Micheal
> >> suggested.  I restarted DM each time.  I was about ready to toss it in
> >> the old minnow pond, that's where everything goes to die here.  Lots of
> >> CRT monitors in there.  LOL  Anyway, I had to install that package to
> >> run that command.  It spit out a oops when I tried to run it after a
> >> copy and paste.  I also installed it on my main rig, just to compare.
> >> On the new rig, the DPI was a fairly large number.  I thought I had the
> >> output saved but it seems to be gone.  My main rig tho showed 80x80 dots
> >> per inch.  I did a duck search, finally found how to set that.  I then
> >> restarted DM and YEPPIE!!!  It was a normal size again.
> >> 
> >> Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
> >> years???  Should newer monitors be set to a higher number for DPI?  Is
> >> that normal?  Why was it using such a high number by default?  I want to
> >> say one was like 200 or something.  It was quite large.  The reason I'm
> >> asking, I may need to set something else to make the screen the right
> >> size but let it use that larger dpi number, if that is what the newer
> >> monitor prefers to use.
> >> 
> >> Now to reboot, see if I have thoughts of that minnow pond again.  :/
> >> 
> >> Dale
> >> 
> >> :-)  :-)
> > 
> > I'm struggling to follow your post because you do not provide specific
> > information on the commands you input, the output you get in your terminal
> > and the observed changes in the monitor.
> > 
> > You also don't provide info on the changes you made in your xorg.conf, or
> > xrandr and the corresponding changes observed each time in your
> > Xorg.0.log.
> > 
> > Strictly speaking, the pixel density of an on-screen digital image is
> > referred to as Pixels Per Inch (PPI), but the term DPI which refers to a
> > printed image of ink Dots Per Inch has stuck.
> > 
> > In addition, there is the physical pixel density of your monitor and the
> > rendered pixel density of the X11 image(s).  Tweaking the latter allows
> > you to scale the display and make images look larger than the native
> > monitor resolution.
> > 
> > You can set the DPI in your xorg.conf, or you can set it with xranrd, or
> > you can set it on the CLI when you launch X, but usually this is not
> > necessary and could mess up the scaling of your fonts, window decorations
> > and symbols too (the font DPI is set differently by setting Xft.dpi: in
> > ~/.Xresources, of the window manager's/DE font settings).
> > 
> > A good starting point is to get the manual of your monitor and look at its
> > published native resolution, e.g. 1920x1080 and the physical monitor size
> > over which this resolution is displayed.  Let's assume this 1920x1080
> > native resolution belongs to a 23" monitor.  A 23" diagonal would
> > correspond to a 20" wide screen real estate.  Consequently the horizontal
> > PPI would be:
> > 
> > PPI = 1920 pixels / 20" = 96
> > 
> > The same resolution on a 24" wide monitor would give a PPI of:
> > 
> > PPI = 1920 pixels / 24" = 80
> > 
> > Obviously a physically wider 24" monitor with the same native screen
> > resolution as a smaller 20" monitor will not look as sharp when viewed
> > from
> > the *same* distance.
> > 
> > Similarly, changing the selected resolution on the same 23" monitor from
> > say 1920 pixels wide to a lower resolution of 1280 pixels gives a PPI of
> > 64.
> > 
> > I leave the calculation of the vertical PPI to the reader.
> > 
> > Usually I start with no xorg.conf and leave the card to detect what the
> > monitor prefers, then use the Scale setting in the desktop settings to
> > increase/decrease (zoom in/zoom out) the displayed scale.  This has the
> > effect of altering the PPI to higher or lower values to improve
> > readability of content.  The above should help you arrive at some
> > practical resolution, but I would start with the native resolution of the
> > monitor and work down from there if you find it difficult to read its
> > display.
> > 
> > NOTE: Using Qt scaling can mess up window decor

Re: [gentoo-user] New bashrc

[Peter Humphrey]

On Saturday, 6 July 2024 17:31:08 BST Dale wrote:

> Hope those files help. 

Thank you Dale. In fact my problem turned out to be an invisible typo in a 
bash script. You know, the sort that isn't there until the umpteenth time you 
look, and there it is after all.  :)

-- 
Regards,
Peter.

[gentoo-user] emerge notice

[Thelma]

I have in my make.conf:

PORTAGE_ELOG_CLASSES="warn error log"
PORTAGE_ELOG_SYSTEM="mail"
PORTAGE_ELOG_MAILURI="i...@domain.com /usr/sbin/sendmail"
PORTAGE_ELOG_MAILFROM="portage"
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"

It used to work, but ever since Rogers took over Shaw network, they started 
making changes to their mail server and most email sent from command line to 
myself via my provider doesn't work.

Is there an alternative, example send these notifications to a file or print 
them at the end of emerge.

--
Thelma

Re: [gentoo-user] emerge notice

[Jude DaShiell]

you could first pipe portage output to tee perhaps portage.log for a file
to hold output then use grep on portage.log to find notifications in
context sofollowing lines of notifications would be preserved.  I've not
used grep with lines of context before yet so don't know how that feature
would work.


--
 Jude 
 "There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo.
 Please use in that order."
 Ed Howdershelt 1940.

On Sat, 6 Jul 2024, Thelma wrote:

> I have in my make.conf:
>
> PORTAGE_ELOG_CLASSES="warn error log"
> PORTAGE_ELOG_SYSTEM="mail"
> PORTAGE_ELOG_MAILURI="i...@domain.com /usr/sbin/sendmail"
> PORTAGE_ELOG_MAILFROM="portage"
> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
>
> It used to work, but ever since Rogers took over Shaw network, they started
> making changes to their mail server and most email sent from command line to
> myself via my provider doesn't work.
>
> Is there an alternative, example send these notifications to a file or print
> them at the end of emerge.
>
>

Re: [gentoo-user] emerge notice

[Thelma]

On 7/6/24 17:46, Jude DaShiell wrote:

you could first pipe portage output to tee perhaps portage.log for a file
to hold output then use grep on portage.log to find notifications in
context sofollowing lines of notifications would be preserved.  I've not
used grep with lines of context before yet so don't know how that feature
would work.


--
  Jude 
  "There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo.
  Please use in that order."
  Ed Howdershelt 1940.


What the command would look like.
Maybe it would be a solution for single emerge but I'm not sure how it would work with 
"emerge -uDNavq world" when a system emerges over 300 packages.

Re: [gentoo-user] New monitor, new problem. Everything LARGE O_O

[Dale]

Michael wrote:
> On Saturday, 6 July 2024 17:11:23 BST Dale wrote:
>> Michael wrote:
>>> On Saturday, 6 July 2024 10:59:30 BST Dale wrote:
 Mark Knecht wrote:
> On Tue, Jul 2, 2024 at 12:44 PM Dale  > wrote:
> 
>
>> I tried it with those options and without.  Neither changed anything. 
>> I
>> originally tried it with no xorg.conf at all.  I was hoping maybe the
>> Nvidia GUI thing would adjust things.  I may try that again.  No
>> xorg.conf and use the GUI thing.  That's what I use to set up my TV and
>> such anyway.  Thing is, the sddm screen is HUGE too.
> 
>
>> :-)  :-)
> ???
>
> xdpyinfo | grep -B2 resolution
>
> ???
 I booted my new rig up again.  Dang that thing.  It was HUGE again.  I
 started reading stuff, mainly about xorg.conf and the available
 settings.  I changed all sorts of stuff, including some things Micheal
 suggested.  I restarted DM each time.  I was about ready to toss it in
 the old minnow pond, that's where everything goes to die here.  Lots of
 CRT monitors in there.  LOL  Anyway, I had to install that package to
 run that command.  It spit out a oops when I tried to run it after a
 copy and paste.  I also installed it on my main rig, just to compare.
 On the new rig, the DPI was a fairly large number.  I thought I had the
 output saved but it seems to be gone.  My main rig tho showed 80x80 dots
 per inch.  I did a duck search, finally found how to set that.  I then
 restarted DM and YEPPIE!!!  It was a normal size again.

 Now the monitor on my main rig is a bit older too.  Maybe 6 or 7
 years???  Should newer monitors be set to a higher number for DPI?  Is
 that normal?  Why was it using such a high number by default?  I want to
 say one was like 200 or something.  It was quite large.  The reason I'm
 asking, I may need to set something else to make the screen the right
 size but let it use that larger dpi number, if that is what the newer
 monitor prefers to use.

 Now to reboot, see if I have thoughts of that minnow pond again.  :/

 Dale

 :-)  :-)
>>> I'm struggling to follow your post because you do not provide specific
>>> information on the commands you input, the output you get in your terminal
>>> and the observed changes in the monitor.
>>>
>>> You also don't provide info on the changes you made in your xorg.conf, or
>>> xrandr and the corresponding changes observed each time in your
>>> Xorg.0.log.
>>>
>>> Strictly speaking, the pixel density of an on-screen digital image is
>>> referred to as Pixels Per Inch (PPI), but the term DPI which refers to a
>>> printed image of ink Dots Per Inch has stuck.
>>>
>>> In addition, there is the physical pixel density of your monitor and the
>>> rendered pixel density of the X11 image(s).  Tweaking the latter allows
>>> you to scale the display and make images look larger than the native
>>> monitor resolution.
>>>
>>> You can set the DPI in your xorg.conf, or you can set it with xranrd, or
>>> you can set it on the CLI when you launch X, but usually this is not
>>> necessary and could mess up the scaling of your fonts, window decorations
>>> and symbols too (the font DPI is set differently by setting Xft.dpi: in
>>> ~/.Xresources, of the window manager's/DE font settings).
>>>
>>> A good starting point is to get the manual of your monitor and look at its
>>> published native resolution, e.g. 1920x1080 and the physical monitor size
>>> over which this resolution is displayed.  Let's assume this 1920x1080
>>> native resolution belongs to a 23" monitor.  A 23" diagonal would
>>> correspond to a 20" wide screen real estate.  Consequently the horizontal
>>> PPI would be:
>>>
>>> PPI = 1920 pixels / 20" = 96
>>>
>>> The same resolution on a 24" wide monitor would give a PPI of:
>>>
>>> PPI = 1920 pixels / 24" = 80
>>>
>>> Obviously a physically wider 24" monitor with the same native screen
>>> resolution as a smaller 20" monitor will not look as sharp when viewed
>>> from
>>> the *same* distance.
>>>
>>> Similarly, changing the selected resolution on the same 23" monitor from
>>> say 1920 pixels wide to a lower resolution of 1280 pixels gives a PPI of
>>> 64.
>>>
>>> I leave the calculation of the vertical PPI to the reader.
>>>
>>> Usually I start with no xorg.conf and leave the card to detect what the
>>> monitor prefers, then use the Scale setting in the desktop settings to
>>> increase/decrease (zoom in/zoom out) the displayed scale.  This has the
>>> effect of altering the PPI to higher or lower values to improve
>>> readability of content.  The above should help you arrive at some
>>> practical resolution, but I would start with the native resolution of the
>>> monitor and work down from there if you find it difficult to read its
>>> display.
>>>
>>> NOTE: Using Qt scaling can mess up window decorations, widgets, etc.  I've

Re: [gentoo-user] New bashrc

[Dale]

Peter Humphrey wrote:
> On Saturday, 6 July 2024 17:31:08 BST Dale wrote:
>
>> Hope those files help. 
> Thank you Dale. In fact my problem turned out to be an invisible typo in a 
> bash script. You know, the sort that isn't there until the umpteenth time you 
> look, and there it is after all.  :)
>


Maybe that was my problem as well.  My main rig update went fairly
well.  The new rig, which had a fresh new set of never altered files,
went sideways.  I really hated over writing the files that way but I
didn't know of a better way. 

Given that things are moving to a directory now, I wish someone would
write a really good wiki page on how the new way works and have some
examples.  One thing I don't know and haven't found a answer too, the
numbers.  Does it read from low to high?  That makes sense.  Does a
setting from a file with a higher number override settings for files
with lower numbers?  That's a biggie.  When I tried to set my PS1
variable, it clashed with a Gentoo file which set the same variable.  It
seems one doesn't override the other but turns into a wreck, with
injuries.  My bash kinda got weird.  I couldn't login at all. 

I suspect someone will write one at some point.  I just wish it was
sooner rather than later.  I'm not clear on a few things. 

Glad to help.  :-D

Dale

:-)  :-) 

P. S.  I might add, xorg.conf is doing the same thing and I have the
same questions about it.  It seems a lot of things are going the
directory route and it can be a good thing, just confusing at times. 

Re: [gentoo-user] Video card temp and fan sensors.

[Dale]

Alexandru N. Barloiu wrote:
> With nvidia driver, you have to use nvidia-smi utility to get that
> information. While the driver takes over the hardware, no other type
> of software can access same sensors. So when using nvidia-drivers, no
> ssensors command.
>

I been having . . . issues with the new rig.  I wasn't able to dig into
this sensor issue so much.  Now that I got it working pretty well, I
fired up gkrellm.  It is my go to monitor app.  The temp for the video
card show up there and gkrellm refers to it as GPU.  So, they exist
somewhere.  I might add, it has been on my main rig for ages which also
uses Nvidia drivers.  The AUXTIN4 matches the temp of the GPU temp on
gkrellm but a google search shows it is the power supply temp.  I'm
digging around but have no idea where gkrellm is getting the temps
from.  They somewhere, gkrellm found them but I have no idea where that
is, yet.  As long as gkrellm works, and my screen works right, I can use
gkrellm to monitor things. 

Still kinda curious tho.

Dale

:-)  :-) 

[gentoo-user] postfix error: External senders are prohibited to send to local recipient

[Thelma]

I have postfix running on two systems, identical configuration (I think)

One system is sending mail, that is accepted by my provider
Backup system is giving me error: /var/log/mail.log

... status=bounced (host mail.domain.com[69.xx.xxx.xxx] said: 550 5.7.1 
... External senders are prohibited to send to local 
recipients without authentication (in reply to RCPT TO command))

Does these two files need special command to activate them? They seem to be 
simple text files.

/etc/postfix/sender_canonical
/etc/postfix/saslpass

Both these files are identical on both systems.

--
Thelma