Re: x : keyboard not working

2017-10-09 Thread Mattia Oss
On Sun, Oct 08, 2017 at 11:11:26PM -0500, David Wright wrote:
> I avoid having to copy those files by appending my changes to
> /etc/console-setup/remap.inc and then running
> dpkg-reconfigure keyboard-configuration.
> But I'm not making major changes like you, just some modifications
> to make the VCs behave like X, and eliminating the annoyance when
> you catch your finger or thumb on Alt as you hit the space bar.
> 
> # Ctrl-arrow keys need to send the same codes as in X/xterm.
> Control keycode 105 = F51
> string F51 = "\033[1;5D"
> Control keycode 106 = F52
> string F52 = "\033[1;5C"
> Control keycode 108 = F53
> string F53 = "\033[1;5B"
> Control keycode 103 = F54
> string F54 = "\033[1;5A"
> 
> # Alt-space may as well produce a space rather than
> # nul Meta_nul or Meta_space
> alt keycode 57 = F41
> string F41 = " "

So this is the right® way to have a custom keyboard layout in Debian? I
always edited the files in /usr/share/X11/xkb but everytime xkb-data is
updated they are silently overwritten.
How do I get something like:
key  { [ slash, underscore, minus ] };

Do you have a good link to share?

Thanks



Re: Crashes in Icedove on Stretch

2017-02-25 Thread Mattia Oss
On Sat, Feb 25, 2017 at 04:40:44PM +0100, Jörg-Volker Peetz wrote:
> Jörg-Volker Peetz wrote on 02/18/17 10:32:
> > Daniel Bareiro wrote on 02/16/17 15:14:
> > 
> >> Thanks for sharing your experience. It would be good to know if it
> >> remains stable after several days. I just applied the change suggested
> >> by Benjamin in another message in this thread.
> >>
> >> Kind regards,
> >> Daniel
> >>
> > Meanwhile I had the first crash of thunderbird. After updating some gtk- and
> > glib related stuff I'm trying it again. If thunderbird still crashes, I 
> > surely
> > apply the setting of the config variable
> > "layers.offmainthreadcomposition.enabled" (OMTC) which is enabled for 
> > faster and
> > smoother composition.
> > 
> Since I suffered another crash of thunderbird, I now flipped
> "layers.offmainthreadcomposition.enabled" to "false". No more crashes so far.
> 
> Regards,
> jvp.

+1 
No more crashes after 10+ days. This option is the devil himself. :)

Bye,
Mattia



Re: Crashes in Icedove on Stretch

2017-02-17 Thread Mattia Oss
On Thu, Feb 16, 2017 at 07:31:25AM -0500, Benjamin Rochefort wrote:
> I think I fixed the random Icedove crashes I was experiencing on Jessie
> by setting layers.offmainthreadcomposition.enabled to false in Icedove's
> config editor.

Thanks for the tip. No more crashes so far since I disabled this option. 
I will post updates. Thunderbird on Sid.



Re: Early boot became slower

2017-01-28 Thread Mattia Oss
On Fri, Jan 27, 2017 at 10:06:09PM +0100, deloptes wrote:
> Mattia Oss wrote:
> 
> > 
> > Anyway thanks for the effort, much appreciated. :)
> 
> Perhaps you should check your plymouth install/setup. I am not ubuntu user.

[I reply here for everybody]

First of all: ok, uploading to google drive wasn't a good idea. My bad,
apologies. I made new videos and uploaded to youtube, I'll post the links.

But first let me clarify one thing because I fear that there is a big
misunderstanding here: there's no problem with the kernel per se, it
doesn't hang, there are no errors. It just prints the output slowly, or
at least slower than before. I *think* that's related to the framebuffer
(and at this point I'm fairly certain it is, will explain later).

So the point of the videos was *not* to show you the output but to show
you *where* the slowdown occurs: right after the kernel starts.
That's why the quality is not high (ok, maybe also because I suck making
videos...).

So for the ones still interested I'll post some more infos.

Since the problem started with linux-image-4.8.0-2-amd64 I'll compare
4.8.0-1 and 4.8.0-2.

Videos:
4.8.0-1 (fast):
https://www.youtube.com/watch?v=NLWB7FyV7jU

4.8.0-2 (slow):
https://www.youtube.com/watch?v=Nc1lgpdgaxQ

Kernel logs:
4.8.0-1:
https://github.com/maistoast/share/blob/master/kernel/log/4.8.0-1/dmesg_4.8.0-1-amd64

4.8.0-2:
https://github.com/maistoast/share/blob/master/kernel/log/4.8.0-2/dmesg_4.8.0-2-amd64

This is the diff of both changelogs:
https://github.com/maistoast/share/blob/master/kernel/cl/linux-image-4.8.0-amd64-changelog.linux.diff

I saw some reference to radeon but I didn't find anything really useful.

I tried, I think, every suggestions you all gave me. If I don't post
the results it's because it didn't work. For example, plymouth (I don't
have it installed), various kernel options (vga, video, splash, etc...).

BUT, I made a progress. :)
I installed linux-source-4.9 and compiled the kernel with the 4.8.0-1
config. The result: it boots fast! :)

This is the kernel log of the custom kernel:
https://github.com/maistoast/share/blob/master/kernel/log/4.9.2/dmesg_4.9.2--bymattia

As you can see it uses simplefb and not vesafb. I'm quite sure that this
is the problem. As Sven Joachim pointed out, the Debian devs disabled
simplefb because it has problems with KMS framebuffer. Reading the link
he provided they disabled the X86_SYSFB and FB_SIMPLE options to fix
some bugs. I think there's no solution for me because these options are
not enabled in the Debian kernel anymore.. :/ 

Se either I use a custom kernel, or I keep my sweet fat characters with
the Debian kernel.

Thanks,
Mattia.



Re: Early boot became slower

2017-01-27 Thread Mattia Oss
On Fri, Jan 27, 2017 at 04:14:57AM -0500, Felix Miata wrote:
> Mattia Oss composed on 2017-01-27 01:34 (UTC+0100):
> 
> > On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:
> 
> > > For the boot menu, or after?
> 
> > To clarify I uploaded some videos (sorry for the crappy quality :/ )
> 
> You haven't answered my question.

Well, apparently you haven't seen my videos. Anyway: right after the
grub menu.

> None of those play for me. The resolution on the initial screens is so poor

This sentence doesn't make sense. Did you play them or not?
They are 1920x1080 with h264 codec in a Matroska container. I think
that's pretty standard. Which player did you use?

By the way, the point of the videos was to show the entity of the
slowdown and, most importantly, WHEN this occurs. Not to show the output.
If you need the kernel output I will provide it by other means, but
certainly not in a video.

> that I can't make out anything useful except to suggest to remove quiet the
> splash= parameter from the cmdline (or change it to splash=0) and see what
> happens without the graphical background or the output supression.

I don't have the splash or quiet parameter in grub (are you using
ubuntu?) but if I use GRUB_TERMINAL=console or GRUB_GFXPAYLOAD_LINUX=text 
I get a super fast and super ugly output. This can be seen in the 3rd
video. And that's what I'm using right now.

Anyway thanks for the effort, much appreciated. :)



Re: Early boot became slower

2017-01-26 Thread Mattia Oss
On Thu, Jan 26, 2017 at 02:18:36PM -0500, Felix Miata wrote:
> 
> For the boot menu, or after?

To clarify I uploaded some videos (sorry for the crappy quality :/ )

linux-image-4.8.0-1-amd64:
https://goo.gl/TsXUBB

This was the last kernel with fast boot. In /etc/default/grub I had:
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep

Since linux-image-4.8.0-2-amd64 the boot process is slower.
linux-image-4.9.0-1-amd64:
https://goo.gl/buOcpj

ok it's not that slow but I think the difference is quite visible.
I said that the problem may be the framebuffer (vesafb/simplefb) only
because this was the only big difference in the 2 dmesg. But it can be
anything.

This is what I used for the moment.
linux-image-4.9.0-1-amd64 with GRUB_GFXPAYLOAD_LINUX=text:
https://goo.gl/16MJgc

> If after, what gfxchip do you have, maybe something other than NVidia,
> AMD/ATI or Intel? Use 'lspci | grep VGA' or 'inxi -c0 -G' to report here.

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
Core Processor Integrated Graphics Controller (rev 06)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Hawaii XT / Grenada XT [Radeon R9 290X/390X]

> Video= tells the kernel to use the specified mode for the KMS framebuffers.
> Pick a mode that matches your display's native resolution to get the
> smallest possible text.
> 
> If one of the above produce a result you like, you can reconfigure Grub to

I tried with video=1920x1080 but there's no difference. 



Re: Early boot became slower

2017-01-26 Thread Mattia Oss
On Wed, Jan 25, 2017 at 08:33:16PM +0100, Sven Joachim wrote:
> On 2017-01-25 16:26 +0100, Mattia Oss wrote:
> 
> > On Tue, Jan 24, 2017 at 05:59:42PM +0100, Mattia Oss wrote:
> >> I use grub2. I tried the "text" kernel parameter: it works but it
> >> obviously isn't what I was looking for.
> >
> > I tried with video=vesafb:off but it doesn't seem to work. I've 
> > recompiled the kernel without vesafb but I get a blank screen (only at 
> > the early phase). 
> 
> Does GRUB_GFXPAYLOAD_LINUX=text in /etc/default/grub help?  Don't forget
> to run update-grub after changing that file.

Yes as mentioned above this works but I have HUGE characters.

> > I'm open to any suggestion...
> 
> I usually put the graphics driver in the initramfs to load it as early
> as possible.
> 
> # echo radeon >> /etc/initramfs-tools/modules
> # update-initramfs -u

Thanks for the suggestions. I tried it but still got a blank screen.
At this point I think I'll stay with GRUB_GFXPAYLOAD_LINUX=text. 
At least it's fast.



Re: Early boot became slower

2017-01-25 Thread Mattia Oss
On Tue, Jan 24, 2017 at 05:59:42PM +0100, Mattia Oss wrote:
> On Tue, Jan 24, 2017 at 05:36:58PM +0100, Sven Joachim wrote:
> > On 2017-01-24 17:13 +0100, Mattia Oss wrote:
> > > Any way to fix this without recompiling?
> > 
> > Try not to load vesafb in the first place.  Which bootloader do you use?
> 
> I use grub2. I tried the "text" kernel parameter: it works but it
> obviously isn't what I was looking for.

I tried with video=vesafb:off but it doesn't seem to work. I've 
recompiled the kernel without vesafb but I get a blank screen (only at 
the early phase). 
I'm open to any suggestion...



Re: Early boot became slower

2017-01-24 Thread Mattia Oss
On Tue, Jan 24, 2017 at 05:36:58PM +0100, Sven Joachim wrote:
> On 2017-01-24 17:13 +0100, Mattia Oss wrote:
> > I see that CONFIG_FB_SIMPLE is not set anymore. Is that a reason for
> > that?
> 
> Apparently the handover to the KMS framebuffer from simplefb does not
> work for all drivers[1].

Thanks for the info.

> > Any way to fix this without recompiling?
> 
> Try not to load vesafb in the first place.  Which bootloader do you use?

I use grub2. I tried the "text" kernel parameter: it works but it
obviously isn't what I was looking for.


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



Early boot became slower

2017-01-24 Thread Mattia Oss
Hi all,

since linux-image-4.8.0-2-amd64 the early phase of my booting process
became slower (~10 secs). I think that it has to do with the
framebuffer. This is the only relevant difference in dmesg:

4.8.0-1-amd64:
simple-framebuffer simple-framebuffer.0: framebuffer at 0xe000, 0x7e9000 
bytes, mapped to 0xc1e20100
simple-framebuffer simple-framebuffer.0: format=x8r8g8b8, mode=1920x1080x32, 
linelength=7680
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
fb: switching to radeondrmfb from simple

4.9.0-1-amd64:
vesafb: framebuffer at 0xe000, mapped to 0xb2370180, using 8128k, 
total 8128k
vesafb: mode is 1920x1080x32, linelength=7680, pages=0
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0
fb: switching to radeondrmfb from VESA VGA

I see that CONFIG_FB_SIMPLE is not set anymore. Is that a reason for
that? Any way to fix this without recompiling?


Thanks in advance,
Mattia



Re: log to journal only

2017-01-09 Thread Mattia Oss
On Mon, Jan 09, 2017 at 08:15:37AM -0500, Henning Follmann wrote:
> I wonder if it safe to disable the "old" way of logging. And if so how
> to
> do that.
Done that 2 days ago. No problems so far. I just removed rsyslog. Read:
/usr/share/doc/systemd/README.Debian.gz


Mattia



mutt and sidebar

2017-01-07 Thread Mattia Oss
Hi,

I'm having a hard time with mutt and the sidebar. What I'm trying to
obtain is the sidebar displaying only the mailboxes of the current
account. So I set up 2 keybindings the source each profile config.
Inside the files there's something like:

set mbox_type = mbox
set folder = "~/.mutt/mail/local"
...
unmailboxes *
mailboxes +inbox +sent +drafts

When I press the relative key, the sidebar change but all numbers set to
0.

inbox   0|
sent0|
drafts  0|

Is there any option that tells the sidebar to update these numbers?


Thanks in advance for any suggestion.



Re: using offlineimap, notmuch and emacs etc....

2017-01-07 Thread Mattia Oss
On Sat, Jan 07, 2017 at 02:53:53PM +, Michael Fothergill wrote:
> mikef@rhinoceros:~$ offlineimap
>  OfflineIMAP 6.3.4
Oh my... I'm really sorry, I thought you were using Sid as I do.
Forget what I wrote. I'm using offlineimap 7.0.12, that's why the option
GmailMaildir is not recognized by your offlineimap.

I'm sorry but you have to wait someone else to help you, maybe with the
same version.

Bye,
Mattia



Re: using offlineimap, notmuch and emacs etc....

2017-01-07 Thread Mattia Oss
On Sat, Jan 07, 2017 at 01:14:21PM +, Michael Fothergill wrote:

I'm also trying to configure offlineimap and mutt, so I'll try to
help.

> I found a web site that explained how to use it in combination with emacs
Always compare more sources as offlineimap is changed a lot recently.

> [Repository Local]
> type = Maildir
use type = GmailMaildir here.

> [Repository MichaelFothergillGmail]
> type = Gmail
> maxconnections=1
> remoteuser = michael.fotherg...@gmail.com
> realdelete=no
> folderfilter = lambda foldername:foldername in ['[Google Mail]/All
> Mail', '[Google Mail]/Sent Mail']
> nametrans = lambda foldername:  re.sub('^\[Google Mail\]/All Mail$', 'all',
> re.sub('^\[Google Mail\]/Sent Mail$', 'sent',foldername))

You have to use nametrans both in the local and remote repository.
Look at this howto:
http://stevelosh.com/blog/2012/10/the-homely-mutt/
But you can do this later. I'd rather just disable this option for the
moment.

> mikef@rhinoceros:~$ offlineimap
Try:
$ offlineimap --info

and post the output.