Re: [gentoo-user] march to cross-compile ASUS laptop

[P Levine]

On Tue, Jul 11, 2017 at 7:06 PM, Andrés Becerra Sandoval
 wrote:
> It says that the microarchitecture is apollo-lake.
>
> What would be the proper march configuration for this box?
>
>
> --
>   Andrés Becerra Sandoval
>

apollo-lake.= goldmont

As gcc appears to have no support as of yet, I would use "-march=silvermont"

goldmont is basically silvermont+

Re: [gentoo-user] Wayland - too early to try?

[Stefan G. Weichinger]

Am 2017-07-11 um 13:37 schrieb Rasmus Thomsen:
> Hello,
> 
> I use GNOME with Wayland for some time and I actually didn't notice that
> I switched until I tried to get synergy working ( mouse sharing
> software, which only works on X ), seems like GDM automatically chose
> Wayland since some upgrade.

just another note: TeamViewer also didn't work for me with Wayland.

Re: [gentoo-user] march to cross-compile ASUS laptop

[R0b0t1]

On Tue, Jul 11, 2017 at 6:06 PM, Andrés Becerra Sandoval
 wrote:
>
> It says that the microarchitecture is apollo-lake.
>
> What would be the proper march configuration for this box?
>

Per the GCC documentation, here are the options you can pass to -march
(described under the section for -mtune):

https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Options.html
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html

Surprisingly it was hard to find this page of the documentation, even
knowing what I was looking for.

You should also refer to the Wiki documentation for -march, found
here: https://wiki.gentoo.org/wiki/GCC_optimization#-march.

Specifically I need to point out the use of cpuinfo2cpuflags-x86. If
you are finding it hard to find the corresponding -march/-mtune
setting for your processor by name, you may need to select an
equivalent setting by looking at the features your CPU supports. You
can also ask the list.

R0b0t1.

Re: [gentoo-user] Re: Wayland - too early to try?

[R0b0t1]

On Tue, Jul 11, 2017 at 10:25 AM, Rich Freeman  wrote:
> On Tue, Jul 11, 2017 at 10:51 AM, Ian Zimmerman  wrote:
>> On 2017-07-11 09:02, Rich Freeman wrote:
>>
>>> > I use GNOME with Wayland for some time and I actually didn't notice
>>> > that I switched until I tried to get synergy working ( mouse sharing
>>> > software, which only works on X ), seems like GDM automatically
>>> > chose Wayland since some upgrade. XWayland works pretty seamlessly
>>> > as well, so I'll just stay with Wayland for now, but it might be
>>> > more annoying to use it with other DEs/WMs.
>>
>>> > However, I have less screen tearing with fullscreen applications
>>> > with Wayland than I had with X ( with radeon + mesa ).
>>
>>> My sense is that this is probably what people would see.  It will
>>> probably work fine for any of the major DEs, but you'll find these
>>> little cases of tools that aren't ported.  One BIG area that will be
>>> affected is X11 forwarding.  I'm not sure if that works over ssh or
>>> not with wayland, but wayland in general doesn't support network
>>> sockets.
>>
>> What about "3rd party" window managers like openbox?  From my limited
>> understanding of wayland, that functionality just goes out of the window
>> (OOPS, sorry); window management becomes a responsibility of the toolkit
>> and there is no way to plug in a different one.
>
> I'm going out on a limb a bit here, but my understanding is not so
> much that it is impossible for arbitrary applications to talk to
> wayland (that seems silly - it is just an API).  Rather, the major
> toolkits simply have already done all the hard work so that if you use
> one of those toolkits then your application will work.
>

I don't think it's been mentioned explicitly yet, but Wayland pretends
to be X11 in the same way your terminal emulator can pretend to be a
VT100.

This choice was made because otherwise applications would have to be
explicitly rewritten for Wayland before most people would switch, and
that's a barrier to entry that would be very hard to overcome.

> I'm sure there is no reason an application that doesn't use qt/gtk/etc
> couldn't just make direct calls to wayland.  However, it will require
> a lot more porting work on the part of upstream, and so it probably
> won't happen quickly.
>
> In the same way an application written to use QT probably can be made
> to work on OSX or Windows with very little additional work, because
> the toolkits provide a single API across all the platforms.  You could
> write an application that works on all these platforms without using a
> toolkit, but then the developer needs to maintain all the API
> abstraction.
>
> Getting back to openbox/etc, I suspect that you have a couple of extremes 
> here:
>
> * Full-fledged DEs like Gnome/KDE.  They have a ton of functionality
> that would be impacted by Wayland, but they also use toolkits that
> have probably already taken care of this.
> * Very minimal window managers (think fvwm/twm/etc).  They may not use
> a toolkit that was ported, but on the other hand their functionality
> is minimal and porting might not be so hard.  Also, there seems to be
> some effort to port more minimal toolkits like motif to wayland.
> * In-between environments (think xfce, openstep, etc).  They don't
> benefit from the toolkit but still have a lot of functionality to
> port.  I heard that xfce is being ported to gtk for just this reason.
>
> I suspect that Wayland is going to drive adoption of gtk/qt much more
> widely.  For the effort of directly porting to Wayland you could just
> port to gtk and then get coverage on other platforms as well.
>
>>
>> Or does xwayland help with that?  I'll be grateful for an explanation of
>> this area, as I'm worried about the future of the X server but I'm also
>> married to openbox.
>>
>
> I suspect that xwayland would cover some of this, but I haven't messed
> with either.
>

Ah, looks like someone was going to mention it then.


In any case if you are asking the question that OP did, I would
suggest Wayland might not be for you. You may not receive any benefit
from using it unless, for some reason, the differing underlying
implementation fixes a bug - but I see this as being a bit of a
stretch, because if you don't go out of your way to run Wayland only
programs, you will still be running X11 on top of Wayland.

Most programs written for Wayland still seem to be at early
experimental stages, and are things like tiling window managers.

R0b0t1.

[gentoo-user] march to cross-compile ASUS laptop

[Andrés Becerra Sandoval]

Hello,

I want to use a build host to create packages for a L402N Asus laptop.

% grep -m1 -A3 "vendor_id" /proc/cpuinfo
vendor_id   : GenuineIntel
cpu family  : 6
model   : 92
model name  : Intel(R) Celeron(R) CPU N3350 @ 1.10GHz

intel has this specs:
http://ark.intel.com/products/95598/Intel-Celeron-Processor-N3350-2M-Cache-up-to-2_4-GHz

and, in the following website:

 https://en.wikichip.org/wiki/intel/celeron/n3350

​It says that the microarchitecture is apollo-lake.

What would be the proper marc​h configuration for this box?


--
  Andrés Becerra Sandoval

Re: [gentoo-user] Re: Wayland - too early to try?

[Mick]

On Wednesday 12 Jul 2017 01:10:00 Mart Raudsepp wrote:
> > I copied /usr/share/xsessions/enlightenment.desktop to
> > /usr/share/wayland-
> > sessions/ and tried to select it in LightDM.  Unfortunately LightDM
> > returns me 
> > back to the login page.  I don't know if this is a result of LightDM
> > not being 
> > compatible with Wayland and friends, or if I need to install some
> > other 
> > package in addition to what has been emerged already.  
> 
> The desktop manager needs to be using wayland to be able to launch
> wayland desktop sessions. LightDM is not such a desktop manager to my
> knowledge and you won't be able to launch any wayland sessions with it.
> 
> Mart

Thanks Mart, what other DM or means do I have to launch enlightenment with 
wayland?  I'm guessing the time honoured startx from a console won't cut it.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

> I copied /usr/share/xsessions/enlightenment.desktop to
> /usr/share/wayland-
> sessions/ and tried to select it in LightDM.  Unfortunately LightDM
> returns me 
> back to the login page.  I don't know if this is a result of LightDM
> not being 
> compatible with Wayland and friends, or if I need to install some
> other 
> package in addition to what has been emerged already.  

The desktop manager needs to be using wayland to be able to launch
wayland desktop sessions. LightDM is not such a desktop manager to my
knowledge and you won't be able to launch any wayland sessions with it.

Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Mick]

On Tuesday 11 Jul 2017 22:27:03 Mart Raudsepp wrote:
> Random information dump on the subject.
> 
> Wayland is no program, it is a protocol, that's it. dev-libs/wayland is
> essentially a helper library to speak that IPC protocol.
> 
> The window manager has to be the compositor and other things as well
> and do the input handling, window drawing, screenshot support, screen
> capture support, etc etc.
> Random programs can not take screenshots, listen to keys (think global
> keys, e.g outside desktop shortcuts/push2talk voip) without some
> protocol between the WM and the program. The Xorg programs for that
> essentially make use of Xorg design security issues to do stuff like
> take screenshots (random program can see your whole desktop screen with
> Xorg), listen to input (keyloggers are trivial with Xorg), etc.
> There are some standardization efforts going on between the desktop in
> various areas of this, to define wayland protocols to more securely
> support these things for applications. In some areas things are still
> lacking.
> 
> To detect native wayland vs Xwayland or Xorg I like to use xprop.
> Running that command and clicking it on a window will give information
> about that window IFF it's using Xwayland or your whole session is in
> Xorg.
> But if you are still using Xorg, then you'll have a /usr/bin/X running.
> There is no X running with a wayland WM, just Xwayland at most for
> programs that don't support wayland natively.
> Xwayland is a rootless X server to run on top of a wayland supporting
> compositor. It's conceptually the same like Xquartz or Xming to run X11
> clients in some other environment.
> 
> Wayland strives towards the "every frame is perfect" mantra. It is very
> hard for toolkits and other things to draw things halfway on monitor
> scan-out, so things like tearing are rather hard to accomplish, albeit
> possible still in certain situations.
> 
> With wayland your programs need to do all the drawing themselves, which
> actually means often pure software rendering, but thanks to the
> smoothness of "every frame is perfect", it'll feel faster on your
> common system. You don't have RENDER extension to do some acceleration
> like you do in Xorg with many toolkits knowing about X RENDER (cairo in
> the gtk+ world). To get hardware acceleration, the toolkit itself needs
> to be able to use OpenGL (full or GLES), Vulkan, or similar. GTK+ 4
> will be able to do both. Games typically already use OpenGL or Vulkan
> and if they run natively on Wayland, they are still accelerated, often
> with some things out of the way compared to Xorg. Programs that don't
> run natively and end up using Xwayland are also accelerated via RENDER,
> as Xwayland makes use of GLAMOR, which implements RENDER in the
> (Xwayland rootless) X server on top of OpenGL. But as said, in practice
> things are fast and smooth already as-is, even if software rendering.
> 
> One caveat of Wayland is that if the WM/compositor crashes, your whole
> graphical session dies, while with Xorg the WM typically just restarts
> and for the session to die, Xorg itself would have to die (and that's
> been ironed out over the decades to very rarely do).
> 
> GNOME is indeed one of the leaders in adoption and implementing various
> extra features on top of it (even middle-click PRIMARY paste,
> seriously). EFL is probably another, and I think plasma is getting
> there. And then you have the dedicated wayland compositors like Sway (a
> i3-compatible approach). I bet there are something similar openbox-like
> out there as well, but openbox itself definitely won't work, as it'd
> have to be the compositor and not talk libX11..
> 
> 
> HTH,
> but probably you should have just googled ;)
> 
> 
> Mart

Thank you very much for a comprehensive information chapter on Wayland!  :-)

Clearly I run Xorg:

 4418 ?SLsl   0:00 /usr/sbin/lightdm
 4427 tty7 Ssl+   1:00  \_ /usr/bin/X :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

xprop does not reveal wayland anywhere either.

I copied /usr/share/xsessions/enlightenment.desktop to /usr/share/wayland-
sessions/ and tried to select it in LightDM.  Unfortunately LightDM returns me 
back to the login page.  I don't know if this is a result of LightDM not being 
compatible with Wayland and friends, or if I need to install some other 
package in addition to what has been emerged already.  
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Wayland - too early to try?

[Mart Raudsepp]

Random information dump on the subject.

Wayland is no program, it is a protocol, that's it. dev-libs/wayland is
essentially a helper library to speak that IPC protocol.

The window manager has to be the compositor and other things as well
and do the input handling, window drawing, screenshot support, screen
capture support, etc etc.
Random programs can not take screenshots, listen to keys (think global
keys, e.g outside desktop shortcuts/push2talk voip) without some
protocol between the WM and the program. The Xorg programs for that
essentially make use of Xorg design security issues to do stuff like
take screenshots (random program can see your whole desktop screen with
Xorg), listen to input (keyloggers are trivial with Xorg), etc.
There are some standardization efforts going on between the desktop in
various areas of this, to define wayland protocols to more securely
support these things for applications. In some areas things are still
lacking.

To detect native wayland vs Xwayland or Xorg I like to use xprop.
Running that command and clicking it on a window will give information
about that window IFF it's using Xwayland or your whole session is in
Xorg.
But if you are still using Xorg, then you'll have a /usr/bin/X running.
There is no X running with a wayland WM, just Xwayland at most for
programs that don't support wayland natively.
Xwayland is a rootless X server to run on top of a wayland supporting
compositor. It's conceptually the same like Xquartz or Xming to run X11
clients in some other environment.

Wayland strives towards the "every frame is perfect" mantra. It is very
hard for toolkits and other things to draw things halfway on monitor
scan-out, so things like tearing are rather hard to accomplish, albeit
possible still in certain situations.

With wayland your programs need to do all the drawing themselves, which
actually means often pure software rendering, but thanks to the
smoothness of "every frame is perfect", it'll feel faster on your
common system. You don't have RENDER extension to do some acceleration
like you do in Xorg with many toolkits knowing about X RENDER (cairo in
the gtk+ world). To get hardware acceleration, the toolkit itself needs
to be able to use OpenGL (full or GLES), Vulkan, or similar. GTK+ 4
will be able to do both. Games typically already use OpenGL or Vulkan
and if they run natively on Wayland, they are still accelerated, often
with some things out of the way compared to Xorg. Programs that don't
run natively and end up using Xwayland are also accelerated via RENDER,
as Xwayland makes use of GLAMOR, which implements RENDER in the
(Xwayland rootless) X server on top of OpenGL. But as said, in practice
things are fast and smooth already as-is, even if software rendering.

One caveat of Wayland is that if the WM/compositor crashes, your whole
graphical session dies, while with Xorg the WM typically just restarts
and for the session to die, Xorg itself would have to die (and that's
been ironed out over the decades to very rarely do).

GNOME is indeed one of the leaders in adoption and implementing various
extra features on top of it (even middle-click PRIMARY paste,
seriously). EFL is probably another, and I think plasma is getting
there. And then you have the dedicated wayland compositors like Sway (a
i3-compatible approach). I bet there are something similar openbox-like 
out there as well, but openbox itself definitely won't work, as it'd
have to be the compositor and not talk libX11..


HTH,
but probably you should have just googled ;)


Mart

Re: [gentoo-user] Re: Wayland - too early to try?

[Rasmus Thomsen]

Hello,
> How do I know if wayland is running and if it has a hand in all this 
> goodness? I don't see any running process called wayland ...
that's because wayland is just the API, you have to look for the compositor you 
use. You can test if you run wayland via "echo $WAYLAND_DISPLAY" ( not too sure 
if all compositors export it though, but I guess they do )
Regards,
Rasmus

Re: [gentoo-user] Re: Wayland - too early to try?

[Mick]

On Tuesday 11 Jul 2017 17:51:03 Franz Fellner wrote:
> > Additional question:  will keyboard selection keybindings for different
> > languages be read off /etc/X11/xorg.conf.d/10-evdev.conf?  In particular,
> > 
> >  Option "XkbLayout"
> >  Option "XkbOptions"
> > 
> > which help me toggle the keyboard between different languages.  Or is a
> > different mechanism required for (X)Wayland?
> 
> You have to go a different route: Either it is directly configurable via WM
> (AFAIK enlightenment has a keybord module) or you have to set
> XKB_DEFAULT_LAYOUT envvar.

OKie dOKie, I set USE=wayland globally and just installed dev-libs/efl- 
and x11-wm/enlightenment- from bar overlay.  I had to disable opengl and 
sdl, enable egl gles and a number of packages were emerged/re-emerged.

I am now running the newly compiled enlightenment and it is more stable than 
before.  Nothing has crashed so far and I have not been able to reproduce the 
previous mesa/dri problems with application tooltips freezing the whole 
desktop.

Also, fonts look clearer, rendering seems faster, compositing smoother.  
Switching languages in line with my settings in 10-evdev.conf is working as it 
should.  However, perhaps it is a silly question:  

How do I know if wayland is running and if it has a hand in all this goodness?

I don't see any running process called wayland ... 

These are the two enlightenment desktop related packages emerged from overlay 
with their flags:

# emerge -1aDv @enlightenment

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   *] dev-libs/efl-:0/::bar  USE="X bmp eet egl fontconfig 
fribidi gif gles ico nls pdf physics png postscript ppm psd pulseaudio sndfile 
ssl svg tga tiff v4l2 wayland webp -avahi -cxx-bindings -debug -doc -drm -
fbcon -glib -gnutls -gstreamer -harfbuzz -ibus -jpeg2k -libuv -opengl (-
pixman) -raw -scim -sdl -static-libs -system-lz4 -systemd {-test} -tslib -xim 
-xine -xpm" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild   R   ~] x11-terms/terminology-1.0.0::gentoo  USE="nls -doc" 0 KiB
[ebuild   R   ~] x11-wm/enlightenment-:0.17/::bar  USE="eeze nls pam 
ukit wayland -doc -egl -pm-utils -static-libs -systemd" 
ENLIGHTENMENT_MODULES="appmenu backlight battery bluez4 clock conf-
applications conf-bindings conf-dialogs conf-display conf-interaction conf-
intl conf-menus conf-paths conf-performance conf-randr conf-shelves conf-theme 
conf-window-manipulation conf-window-remembers connman contact cpufreq 
everything fileman fileman-opinfo gadman ibar ibox lokker mixer msgbus music-
control notification pager pager16 quickaccess shot start syscon systray tasks 
teamwork temperature tiling winlist wizard xkbswitch -access -packagkit -wl-
desktop-shell -wl-drm -wl-fb -wl-x11" 0 KiB

Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB

2nd question:

What are the following enlightenment modules for?

wl-desktop-shell
wl-drm
wl-fb
wl-x11

Do I need these to run wayland, or is the wayland USE flang alone sufficient?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Wayland - too early to try?

[Franz Fellner]

>
> Additional question:  will keyboard selection keybindings for different
> languages be read off /etc/X11/xorg.conf.d/10-evdev.conf?  In particular,
>
>  Option "XkbLayout"
>  Option "XkbOptions"
>
> which help me toggle the keyboard between different languages.  Or is a
> different mechanism required for (X)Wayland?
>

You have to go a different route: Either it is directly configurable via WM
(AFAIK enlightenment has a keybord module) or you have to set
XKB_DEFAULT_LAYOUT envvar.

Re: [gentoo-user] Re: Wayland - too early to try?

[Franz Fellner]

Just porting to a toolkit that "supports" Wayland won't be much help to
window managers. A WM has to implement the wayland server side (compositor)
while applications are clients. The toolkits abstract away the X/wayland
client API calls (E.G. Qt platform plugins) so you simply create your
widgets, setup your (toolkit native) callbacks and are done. But as soon as
you call X-specific functions in your applications things will get harder.
Qt now also implements a wayland-compostior which HELPS creating a wayland
server. But still you need to do quite some work. Porting to gtk3 (xfce...
) will have a similar impact: It won't allow XFCE to automatically run on X
and Wayland. Probably it makes some things easier but in the end there is
not so much the toolkit can abstract away in terms of creating a
compositor/server/WM.

Personally I tried to get running Plasma on wayland several times and while
I finally got it started there were so many crashes (e.g. some applications
esp. those having to run on XWayland, but also systemsettings) and issues
with managing windows that I gave up on it for the moment. Gnome might be a
different thing as they go wayland exclusively and have a working
implementation for a longer time than kde. I also tried enlightenment with
wayland which didn't run more stable than with X :(

2017-07-11 17:25 GMT+02:00 Rich Freeman :

> On Tue, Jul 11, 2017 at 10:51 AM, Ian Zimmerman 
> wrote:
> > On 2017-07-11 09:02, Rich Freeman wrote:
> >
> >> > I use GNOME with Wayland for some time and I actually didn't notice
> >> > that I switched until I tried to get synergy working ( mouse sharing
> >> > software, which only works on X ), seems like GDM automatically
> >> > chose Wayland since some upgrade. XWayland works pretty seamlessly
> >> > as well, so I'll just stay with Wayland for now, but it might be
> >> > more annoying to use it with other DEs/WMs.
> >
> >> > However, I have less screen tearing with fullscreen applications
> >> > with Wayland than I had with X ( with radeon + mesa ).
> >
> >> My sense is that this is probably what people would see.  It will
> >> probably work fine for any of the major DEs, but you'll find these
> >> little cases of tools that aren't ported.  One BIG area that will be
> >> affected is X11 forwarding.  I'm not sure if that works over ssh or
> >> not with wayland, but wayland in general doesn't support network
> >> sockets.
> >
> > What about "3rd party" window managers like openbox?  From my limited
> > understanding of wayland, that functionality just goes out of the window
> > (OOPS, sorry); window management becomes a responsibility of the toolkit
> > and there is no way to plug in a different one.
>
> I'm going out on a limb a bit here, but my understanding is not so
> much that it is impossible for arbitrary applications to talk to
> wayland (that seems silly - it is just an API).  Rather, the major
> toolkits simply have already done all the hard work so that if you use
> one of those toolkits then your application will work.
>
> I'm sure there is no reason an application that doesn't use qt/gtk/etc
> couldn't just make direct calls to wayland.  However, it will require
> a lot more porting work on the part of upstream, and so it probably
> won't happen quickly.
>
> In the same way an application written to use QT probably can be made
> to work on OSX or Windows with very little additional work, because
> the toolkits provide a single API across all the platforms.  You could
> write an application that works on all these platforms without using a
> toolkit, but then the developer needs to maintain all the API
> abstraction.
>
> Getting back to openbox/etc, I suspect that you have a couple of extremes
> here:
>
> * Full-fledged DEs like Gnome/KDE.  They have a ton of functionality
> that would be impacted by Wayland, but they also use toolkits that
> have probably already taken care of this.
> * Very minimal window managers (think fvwm/twm/etc).  They may not use
> a toolkit that was ported, but on the other hand their functionality
> is minimal and porting might not be so hard.  Also, there seems to be
> some effort to port more minimal toolkits like motif to wayland.
> * In-between environments (think xfce, openstep, etc).  They don't
> benefit from the toolkit but still have a lot of functionality to
> port.  I heard that xfce is being ported to gtk for just this reason.
>
> I suspect that Wayland is going to drive adoption of gtk/qt much more
> widely.  For the effort of directly porting to Wayland you could just
> port to gtk and then get coverage on other platforms as well.
>
> >
> > Or does xwayland help with that?  I'll be grateful for an explanation of
> > this area, as I'm worried about the future of the X server but I'm also
> > married to openbox.
> >
>
> I suspect that xwayland would cover some of this, but I haven't messed
> with either.
>
> --
> Rich
>
>

Re: [gentoo-user] Re: Wayland - too early to try?

[Mick]

On Tuesday 11 Jul 2017 07:51:19 Ian Zimmerman wrote:
> On 2017-07-11 09:02, Rich Freeman wrote:
> > > I use GNOME with Wayland for some time and I actually didn't notice
> > > that I switched until I tried to get synergy working ( mouse sharing
> > > software, which only works on X ), seems like GDM automatically
> > > chose Wayland since some upgrade. XWayland works pretty seamlessly
> > > as well, so I'll just stay with Wayland for now, but it might be
> > > more annoying to use it with other DEs/WMs.
> > > 
> > > However, I have less screen tearing with fullscreen applications
> > > with Wayland than I had with X ( with radeon + mesa ).
> > 
> > My sense is that this is probably what people would see.  It will
> > probably work fine for any of the major DEs, but you'll find these
> > little cases of tools that aren't ported.  One BIG area that will be
> > affected is X11 forwarding.  I'm not sure if that works over ssh or
> > not with wayland, but wayland in general doesn't support network
> > sockets.
> 
> What about "3rd party" window managers like openbox?  From my limited
> understanding of wayland, that functionality just goes out of the window
> (OOPS, sorry); window management becomes a responsibility of the toolkit
> and there is no way to plug in a different one.
> 
> Or does xwayland help with that?  I'll be grateful for an explanation of
> this area, as I'm worried about the future of the X server but I'm also
> married to openbox.

Additional question:  will keyboard selection keybindings for different 
languages be read off /etc/X11/xorg.conf.d/10-evdev.conf?  In particular,

 Option "XkbLayout" 
 Option "XkbOptions"

which help me toggle the keyboard between different languages.  Or is a 
different mechanism required for (X)Wayland?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Wayland - too early to try?

[Rich Freeman]

On Tue, Jul 11, 2017 at 10:51 AM, Ian Zimmerman  wrote:
> On 2017-07-11 09:02, Rich Freeman wrote:
>
>> > I use GNOME with Wayland for some time and I actually didn't notice
>> > that I switched until I tried to get synergy working ( mouse sharing
>> > software, which only works on X ), seems like GDM automatically
>> > chose Wayland since some upgrade. XWayland works pretty seamlessly
>> > as well, so I'll just stay with Wayland for now, but it might be
>> > more annoying to use it with other DEs/WMs.
>
>> > However, I have less screen tearing with fullscreen applications
>> > with Wayland than I had with X ( with radeon + mesa ).
>
>> My sense is that this is probably what people would see.  It will
>> probably work fine for any of the major DEs, but you'll find these
>> little cases of tools that aren't ported.  One BIG area that will be
>> affected is X11 forwarding.  I'm not sure if that works over ssh or
>> not with wayland, but wayland in general doesn't support network
>> sockets.
>
> What about "3rd party" window managers like openbox?  From my limited
> understanding of wayland, that functionality just goes out of the window
> (OOPS, sorry); window management becomes a responsibility of the toolkit
> and there is no way to plug in a different one.

I'm going out on a limb a bit here, but my understanding is not so
much that it is impossible for arbitrary applications to talk to
wayland (that seems silly - it is just an API).  Rather, the major
toolkits simply have already done all the hard work so that if you use
one of those toolkits then your application will work.

I'm sure there is no reason an application that doesn't use qt/gtk/etc
couldn't just make direct calls to wayland.  However, it will require
a lot more porting work on the part of upstream, and so it probably
won't happen quickly.

In the same way an application written to use QT probably can be made
to work on OSX or Windows with very little additional work, because
the toolkits provide a single API across all the platforms.  You could
write an application that works on all these platforms without using a
toolkit, but then the developer needs to maintain all the API
abstraction.

Getting back to openbox/etc, I suspect that you have a couple of extremes here:

* Full-fledged DEs like Gnome/KDE.  They have a ton of functionality
that would be impacted by Wayland, but they also use toolkits that
have probably already taken care of this.
* Very minimal window managers (think fvwm/twm/etc).  They may not use
a toolkit that was ported, but on the other hand their functionality
is minimal and porting might not be so hard.  Also, there seems to be
some effort to port more minimal toolkits like motif to wayland.
* In-between environments (think xfce, openstep, etc).  They don't
benefit from the toolkit but still have a lot of functionality to
port.  I heard that xfce is being ported to gtk for just this reason.

I suspect that Wayland is going to drive adoption of gtk/qt much more
widely.  For the effort of directly porting to Wayland you could just
port to gtk and then get coverage on other platforms as well.

>
> Or does xwayland help with that?  I'll be grateful for an explanation of
> this area, as I'm worried about the future of the X server but I'm also
> married to openbox.
>

I suspect that xwayland would cover some of this, but I haven't messed
with either.

-- 
Rich

[gentoo-user] Re: Wayland - too early to try?

[Ian Zimmerman]

On 2017-07-11 09:02, Rich Freeman wrote:

> > I use GNOME with Wayland for some time and I actually didn't notice
> > that I switched until I tried to get synergy working ( mouse sharing
> > software, which only works on X ), seems like GDM automatically
> > chose Wayland since some upgrade. XWayland works pretty seamlessly
> > as well, so I'll just stay with Wayland for now, but it might be
> > more annoying to use it with other DEs/WMs.

> > However, I have less screen tearing with fullscreen applications
> > with Wayland than I had with X ( with radeon + mesa ).

> My sense is that this is probably what people would see.  It will
> probably work fine for any of the major DEs, but you'll find these
> little cases of tools that aren't ported.  One BIG area that will be
> affected is X11 forwarding.  I'm not sure if that works over ssh or
> not with wayland, but wayland in general doesn't support network
> sockets.

What about "3rd party" window managers like openbox?  From my limited
understanding of wayland, that functionality just goes out of the window
(OOPS, sorry); window management becomes a responsibility of the toolkit
and there is no way to plug in a different one.

Or does xwayland help with that?  I'll be grateful for an explanation of
this area, as I'm worried about the future of the X server but I'm also
married to openbox.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Re: [gentoo-user] Wayland - too early to try?

[Mick]

On Tuesday 11 Jul 2017 09:02:59 Rich Freeman wrote:
> On Tue, Jul 11, 2017 at 7:37 AM, Rasmus Thomsen
> 
>  wrote:
> > I use GNOME with Wayland for some time and I actually didn't notice that I
> > switched until I tried to get synergy working ( mouse sharing software,
> > which only works on X ), seems like GDM automatically chose Wayland since
> > some upgrade. XWayland works pretty seamlessly as well, so I'll just stay
> > with Wayland for now, but it might be more annoying to use it with other
> > DEs/WMs.
> > However, I have less screen tearing with fullscreen applications with
> > Wayland than I had with X ( with radeon + mesa ).
> 
> My sense is that this is probably what people would see.  It will
> probably work fine for any of the major DEs, but you'll find these
> little cases of tools that aren't ported.  One BIG area that will be
> affected is X11 forwarding.  I'm not sure if that works over ssh or
> not with wayland, but wayland in general doesn't support network
> sockets.

Thank you both.  I don't forward this desktop, although I connect with RDP to 
various Vbox desktops, I take it these won't be affected.

I'll give it a spin and see how it goes.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Wayland - too early to try?

[Rich Freeman]

On Tue, Jul 11, 2017 at 7:37 AM, Rasmus Thomsen
 wrote:
>
> I use GNOME with Wayland for some time and I actually didn't notice that I
> switched until I tried to get synergy working ( mouse sharing software,
> which only works on X ), seems like GDM automatically chose Wayland since
> some upgrade. XWayland works pretty seamlessly as well, so I'll just stay
> with Wayland for now, but it might be more annoying to use it with other
> DEs/WMs.
> However, I have less screen tearing with fullscreen applications with
> Wayland than I had with X ( with radeon + mesa ).
>

My sense is that this is probably what people would see.  It will
probably work fine for any of the major DEs, but you'll find these
little cases of tools that aren't ported.  One BIG area that will be
affected is X11 forwarding.  I'm not sure if that works over ssh or
not with wayland, but wayland in general doesn't support network
sockets.

-- 
Rich

Re: [gentoo-user] How to remove a package from a profile?

[foxfell]

Hi,
LMGFY, https://forums.gentoo.org/viewtopic-t-963412-start-0.html

2017-07-11 15:07 GMT+03:00 Alan McKinnon :

> On 11/07/2017 13:51, Ста Деюс wrote:
> > Hi.
> >
> >
> > Is it possible to remove a package from a profile? -- I try to remove
> > absolutely unnecessary to me openssh package from default/linux/x86
> > profile that beside each time necessity to compile, just reduces system
> > security. So, i did mask it, having created an openssh file
> > in /etc/portage/packages.mask dir. Removed already installed package
> > from the system and then tried to update the system. -- Openssh is
> > enlisted to be compiled/installed among other packages! So, what's the
> > recipe here?
> >
> >
> > Thank you for your time,
> > Sthu.
> >
>
>
> Yeah, you really don't want to do that.
>
> virtual/ssh is listed in the base profile, so every Gentoo system on the
> planet starts off with it included. It's the server and the client, so
> if you don't want the server running, then don't start it (your security
> argument doesn't really hold water), and the client is about the second
> most useful piece of software there is, up there with compilers and shells
>
> It's not a big package:
> $ equery size openssh
>  * net-misc/openssh-7.5_p1-r2
>  Total files : 70
>  Total size  : 5.68 MiB
>
> Compiles rather quickly too:
> $ genlop -t openssh
>  * net-misc/openssh
>  Tue Jul  4 04:43:52 2017 >>> net-misc/openssh-7.5_p1-r2
>merge time: 53 seconds.
>
> So I think you are cargo-culting and trying to remove something with
> zero understanding of why it is there. But it annoys you
>
> But if you really want to shoot both feet off at the knees, read on:
>
> You can't modify a profile, nothing in them is optional. You have to
> take an existing profile then extend and modify it. Look at
> defaults/linux/x86/* and see how they extend x86.
>
> The magic line that does what you desire goes in a file called
> "packages", look at this example from prefix:
>
> $ cat ./prefix/linux/packages
> # Here we remove packages that default/linux/packages pulls in and have
> # no business being in Gentoo Prefix
> -*sys-apps/busybox
> -*sys-apps/util-linux
>
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>

Re: [gentoo-user] How to remove a package from a profile?

[Alan McKinnon]

On 11/07/2017 13:51, Ста Деюс wrote:
> Hi.
> 
> 
> Is it possible to remove a package from a profile? -- I try to remove
> absolutely unnecessary to me openssh package from default/linux/x86
> profile that beside each time necessity to compile, just reduces system
> security. So, i did mask it, having created an openssh file
> in /etc/portage/packages.mask dir. Removed already installed package
> from the system and then tried to update the system. -- Openssh is
> enlisted to be compiled/installed among other packages! So, what's the
> recipe here?
> 
> 
> Thank you for your time,
> Sthu.
> 


Yeah, you really don't want to do that.

virtual/ssh is listed in the base profile, so every Gentoo system on the
planet starts off with it included. It's the server and the client, so
if you don't want the server running, then don't start it (your security
argument doesn't really hold water), and the client is about the second
most useful piece of software there is, up there with compilers and shells

It's not a big package:
$ equery size openssh
 * net-misc/openssh-7.5_p1-r2
 Total files : 70
 Total size  : 5.68 MiB

Compiles rather quickly too:
$ genlop -t openssh
 * net-misc/openssh
 Tue Jul  4 04:43:52 2017 >>> net-misc/openssh-7.5_p1-r2
   merge time: 53 seconds.

So I think you are cargo-culting and trying to remove something with
zero understanding of why it is there. But it annoys you

But if you really want to shoot both feet off at the knees, read on:

You can't modify a profile, nothing in them is optional. You have to
take an existing profile then extend and modify it. Look at
defaults/linux/x86/* and see how they extend x86.

The magic line that does what you desire goes in a file called
"packages", look at this example from prefix:

$ cat ./prefix/linux/packages
# Here we remove packages that default/linux/packages pulls in and have
# no business being in Gentoo Prefix
-*sys-apps/busybox
-*sys-apps/util-linux


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] How to remove a package from a profile?

[Ста Деюс]

Hi.


Is it possible to remove a package from a profile? -- I try to remove
absolutely unnecessary to me openssh package from default/linux/x86
profile that beside each time necessity to compile, just reduces system
security. So, i did mask it, having created an openssh file
in /etc/portage/packages.mask dir. Removed already installed package
from the system and then tried to update the system. -- Openssh is
enlisted to be compiled/installed among other packages! So, what's the
recipe here?


Thank you for your time,
Sthu.

Re: [gentoo-user] Wayland - too early to try?

[Rasmus Thomsen]

Hello,

I use GNOME with Wayland for some time and I actually didn't notice that I 
switched until I tried to get synergy working ( mouse sharing software, which 
only works on X ), seems like GDM automatically chose Wayland since some 
upgrade. XWayland works pretty seamlessly as well, so I'll just stay with 
Wayland for now, but it might be more annoying to use it with other DEs/WMs.
However, I have less screen tearing with fullscreen applications with Wayland 
than I had with X ( with radeon + mesa ).

Regards,
Rasmus

 Original Message 
On 11 Jul 2017, 13:09, Mick wrote:

> Hi All,
>
> Reading about Wayland as the next big architectural switch in windowing for
> Linux, I have been thinking if it is time to switch to Wayland. I don't know
> if Wayland will be the way the Linux desktop will be running in the future, if
> there will be a migration path to it, a big switch over, or what else.
>
> I'm trying to overcome a mesa/dri bug which is crashing enlightenment's
> compositor and thought Wayland may use mesa not/less/differently. Have you
> tried the switch and are there any gotchas at this stage, or is it straight
> forward?
> --
> Regards,
> Mick

[gentoo-user] Wayland - too early to try?

[Mick]

Hi All,

Reading about Wayland as the next big architectural switch in windowing for 
Linux, I have been thinking if it is time to switch to Wayland.  I don't know 
if Wayland will be the way the Linux desktop will be running in the future, if 
there will be a migration path to it, a big switch over, or what else.

I'm trying to overcome a mesa/dri bug which is crashing enlightenment's 
compositor and thought Wayland may use mesa not/less/differently.  Have you 
tried the switch and are there any gotchas at this stage, or is it straight 
forward?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Is this an alsa th'ang?

[Mick]

On Tuesday 11 Jul 2017 11:58:44 Marc Joliet wrote:
> Am Dienstag, 11. Juli 2017, 08:01:21 CEST schrieb Mick:
> > Specifically why is it
> > trying to find conf.c file from the fs path it happened to have been
> > compiled in ...
> 
> It's not trying to find anything, those are regular debugging messages, most
> likely using the __FILE__ and __LINE__ macros.
> 
> HTH

Thanks Mark, I hadn't noticed the same with other apps I happened to have 
launched from a terminal, but I don't do this often anyway.  I'll just ignore 
these messages then.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Is this an alsa th'ang?

[Marc Joliet]

Am Dienstag, 11. Juli 2017, 08:01:21 CEST schrieb Mick:
> Specifically why is it
> trying to find conf.c file from the fs path it happened to have been
> compiled in ...

It's not trying to find anything, those are regular debugging messages, most 
likely 
using the __FILE__ and __LINE__ macros.

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Is this an alsa th'ang?

[Mick]

On Monday 10 Jul 2017 18:38:17 Ian Zimmerman wrote:
> On 2017-07-11 00:11, Mick wrote:
> > A few days ago I noticed as the operc messages pass by at boot time,
> > alsasound boot service was complaining it can't find some
> > files/settings.
> 
> This may not be relevant, but just in case:  I often get ALSA warnings
> when booting with a newly built kernel.  Apparently the way it stores
> the mixer settings depends on the kernel version, and it gets slightly
> confused when it finds ones saved under an earlier kernel.
> 
> This has been happening for as long as I remember, on any distro, and I
> learned to ignore it, because sound always works okay in spite of it.

The boot error messages of alsasound not being able to set this or that do not 
come up every time.  They showed up when I booted first thing this morn, then 
I set up rc logging and rebooted.  No messages from alsa.  :-/

Speakers & microphone work fine each time here too.

What perplexes me is why alsa comes up with all these messages when an 
application calls it - linphone in this instance.  Specifically why is it 
trying to find conf.c file from the fs path it happened to have been compiled 
in ...
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.